supermagnum/galdralag-firmwareUma tentativa de framework criptográfico para Baochip-1x .
This project is registered with the Open Invention Network (OIN). OIN is a defensive patent pool: members cross-license Linux-related patents so participants can ship and use open-source software with reduced patent exposure.
Status: À espera de hardware para testes. https://www.crowdsupply.com/baochip/dabao/updates/our-campaign-has-launched
Firmware para dispositivos Baochip-1x (placa de avaliação Dabao) que executam o microkernel Xous, compilado para riscv32imac-unknown-none-elf.
Está localizado aqui: https://www.baochip.com/
O dispositivo é um token de segurança de hardware na mesma categoria que dispositivos da classe Nitrokey, com comportamento de smartcard classe OpenPGP e um cofre encriptado. A stack completa de hardware — RTL, esquemas, bootloader, SO — é open source e auditável.
A especificação de hardware, modelo de arranque, tabelas de requisitos e uso de ComboHash/PKE estão documentados em Supermagnum/Baochip-1x-firmware. A placa de avaliação Dabao (KiCad, esquemas, interruptores, pinout) está em baochip/dabao. Para entrar no modo bootloader para flashing, prima SW2 para alternar (veja o esquema desse repositório). Notas de arquitetura para este repositório: docs/ARCHITECTURE.md.
A ferramenta do anfitrião Galdra mantém um diretório SQLite local de destinatários (contactos). Cada identidade armazenada inclui material de chave pública mais rótulos sidecar opcionais (veja a tabela abaixo). Estas etiquetas residem na base de dados do anfitrião e, para chaves Galdra, no contact store no chip (crates/contact-store). Elas não estão magicamente ligadas a IDs de Utilizador OpenPGP a menos que as alinhe você mesmo, e não são criptograficamente afirmadas a menos que as verifique fora de banda. Opcionalmente, galdra keyserver push pode enviar campos sobrepostos para um registo do projeto como JSON juntamente com a chave pública exportada. A proveniência por campo no token usa SelfAttested, HostVerified, RegistrySync e OobVerified (veja Comparação de metadados (GnuPG vs Galdra) e o layout do contact store em docs/RRAM_LAYOUT.md).
Detalhes do lado do anfitrião e comportamento CLI: docs/GALDRA-TOOL.md. Layout do fio e contagens de slots: crates/contact-store/src/layout.rs e docs/RRAM_LAYOUT.md.
Este firmware é um token de segurança de hardware para Baochip-1x: uma aplicação de cartão OpenPGP sobre USB CCID, com um cofre no dispositivo, política de PIN e funcionalidades específicas do repositório (perfis de cifra — pode empilhar até quatro cifras simétricas diferentes numa cascata, cada uma com a sua própria chave derivada; veja Capacidades das chaves), fluxos relacionados com Shamir, ECDH efémero autenticado onde implementado, e ferramentas de anfitrião Galdra). O principal alvo de interoperabilidade é o uso de cartão OpenPGP ao estilo GnuPG, não todos os protocolos de token no mercado.
Este firmware não é:
Exclusões ao nível das crates alinhadas com as mesmas restrições estão listadas em Crates Explicitly Excluded em docs/future-todo.md.
CESS: Este firmware está em conformidade com CESS para as construções normativas implementadas na árvore (incluindo Modo A AEAD exterior, HKDF-BLAKE3 para K_outer, e divisão Shamir byte-wise GF(2^8)). A declaração de alinhamento completa, registo de desvios e nível de certificação (por exemplo CESS-CORE para a camada fixa completa) estão documentados em docs/CESS_CONFORMANCE.md e CESS (padrão aberto relacionado) abaixo.
A lógica da aplicação OpenPGP / CCID está em crates/usb-personality. No Xous, o serviço USB que expõe CCID é usb-bao1x (no seu checkout de xous-core), compilado com a feature ccid-openpgp, usando crates/baochip-openpgp para a janela RRAM OpenPGP e provisionamento. Layout: docs/RRAM_LAYOUT.md. Lacunas pré-produção (UX do PIN do operador, aprovação do mapa da plataforma): Limitações conhecidas / trabalho pendente.
O objetivo geral continua a ser um firmware de token de segurança de hardware completo, testado e open source: comportamento estilo cartão OpenPGP para GnuPG sobre CCID (veja Compatibilidade OpenPGP e GnuPG), mais funcionalidades adicionais no dispositivo atualmente não definidas pelo padrão de cartão OpenPGP — ECDH efémero com forward secrecy, Shamir K-of-N, perfis agnósticos a cifras, volume isca microSD — conforme resumido em Padrões vs. funcionalidades específicas do firmware. Tudo em RTL aberto com bootloader reproduzível.
O firmware expedível para Baochip-1x é assinado com Ed25519. Assina a imagem do firmware com uma chave privada Ed25519; o GnuPG pode fazer isto com gpg --sign usando uma subchave de assinatura Ed25519 (o fluxo de trabalho usual de assinatura destacada OpenPGP, adaptado ao empacotamento que a sua compilação emitir). A ROM boot0 imutável no SoC verifica essa assinatura contra as chaves públicas correspondentes gravadas no dispositivo (e o manifesto de chaves mais amplo para a cadeia de arranque) antes de a próxima fase — boot1 — poder ser executada. O boot1 carrega então imagens de aplicação assinadas (por exemplo, blobs UF2 entregues através de armazenamento USB em massa no modo bootloader). As peças padrão transportam quatro chaves públicas Ed25519 no chip (funções como implantação de código, beta e desenvolvedor); boot0 / boot1 impõem uma política de desconfiança mútua entre Baochip e chaves de assinatura de terceiros. Fluxo de arranque completo, entrega UF2, consola, atualizações boot1 e modelo de segurança: Getting Started with Baochip Targets no xous-core.
Nem todos os testes correm em cada comando; isso é intencional.
xtask não no teste predefinido do workspace: A receita comum é cargo test --workspace --exclude xtask porque xtask é uma crate de orquestração de compilação. Execute cargo test -p xtask quando quiser os seus testes.#[ignore]: Estes são ignorados a menos que passe --ignored (e quaisquer filtros de crate necessários). As razões incluem: cobertura já exercida em testes unitários focados (e.g. zeroização pós-drop), casos lentos (e.g. geração de chave RSA) e fluxos dependentes de hardware ou token em ferramentas do anfitrião como galdra que precisam de um dispositivo conectado ou fixtures.test-all --no-fuzz: Salta o passo cargo-fuzz para manter CI ou execuções rápidas curtas e evitar exigir uma toolchain nightly para esse passo; execute cargo run -p xtask -- test-all sem --no-fuzz, ou invoque os alvos de fuzz separadamente (veja ).Também se pode verificar a integridade das crates com isto quando o pr for fechado: https://github.com/rust-lang/cargo/issues/16850
Estado: Pronto para testes por humanos, em hardware real — não existe versão pronta para produção. Está escrito em Rust usando crates criptográficos validados e auditados. As primitivas criptográficas são extraídas exclusivamente de dependências auditadas do workspace. Algoritmos pós-quânticos estão com feature gate e marcados PENDENTE AUDITORIA INDEPENDENTE. Veja Estado pós-quântico.
Nota: Partes deste projeto foram desenvolvidas com assistência de IA (Claude, Anthropic). O design, escolhas criptográficas e decisões de segurança não foram revistos por um criptógrafo profissional. Trate isto como um projeto experimental e aplique o seu próprio julgamento crítico. Recomenda-se fortemente uma revisão independente por especialistas antes de qualquer implantação em produção.
Está pronto para testes por humanos. Você decide se deve compilar ou executar qualquer parte deste software; podem existir erros que testes unitários, fuzzing e outras verificações não encontraram. Usar uma máquina virtual opcional para experimentação reduz o risco para o seu sistema anfitrião, mas não o elimina. Resultados detalhados estão em Resultados dos testes (docs/TEST_RESULTS.md#run-metadata). Definições em linguagem simples (A–Z) de termos técnicos: Glossário.
O desenvolvedor principal tem uma condição neurológica relacionada com discalculia. A discalculia afeta o sentido numérico e o processamento simbólico relacionado de formas que, para ele, tornam a programação tradicional — edição manual de código como o único fluxo de trabalho — não exequível sem ferramentas assistidas (por exemplo, editores de IA conversacionais). Essa restrição é distinta da correção: os revisores devem ainda pesar os testes, fuzzing e auditoria independente conforme documentado noutros pontos desta página.
Um criptógrafo ou implementador sério a revisar o Galdralag normalmente abrirá crates/vault/tests/ e crates/cipher-profile/tests/ antes de ler prosa. O conjunto de testes é a prova de trabalho: codifica conhecimento de domínio que não pode ser substituído apenas por narrativa.
Isso não é uma razão para esconder o ponto de todos os outros. Pessoas a avaliar o projeto para aquisição, a decidir se contribuem ou a enviar código sem formação profunda em metodologia de teste criptográfico ainda merecem uma indicação para a evidência concreta.
O que olhar: O material de conformidade inclui exemplos trabalhados RFC 8439 para ChaCha20-Poly1305 em crates/vault/tests/rfc_vectors/, JSON Wycheproof empacotado para casos limite de ChaCha20-Poly1305 e Brainpool ECDH/ECDSA em crates/vault/tests/data/wycheproof/, vetores BSI TR-03111 para BrainpoolP256r1 e P384r1 em crates/vault/tests/bsi_vectors/, vetores de referência oficiais BLAKE3 (todos os 35 comprimentos de entrada, todos os três modos) em crates/vault/tests/blake3_vectors.json, vetores de especificação Twofish (1203 casos incluindo Monte Carlo) em crates/vault/tests/twofish_vectors.json, e a fixture KAT da cascata CESS do próprio projeto com intermediários verificados independentemente em crates/cipher-profile/tests/fixtures/cascade_cess_kat.json. Juntos, estes são a verdade fundamental que o executor e revisores podem exercitar com cargo test --workspace e python3 scripts/verify_cascade_kats.py.RFC 8439 é publicada pelo Internet Engineering Task Force (IETF), a organização que padroniza grande parte do funcionamento da internet. RFCs (Request for Comments) são a forma usual para protocolos e muitas especificações criptográficas. RFC 8439 define a criptografia autenticada ChaCha20-Poly1305 (baseada nos designs de Daniel Bernstein) e inclui exemplos concretos com entradas específicas e saídas esperadas para que implementações independentes possam verificar se correspondem ao padrão byte por byte. O texto simples amplamente reproduzido começando com aparece nos exemplos do apêndice da RFC: se seu código reproduz exatamente a saída AEAD, você tem uma verificação forte de que implementou a construção corretamente. É o análogo criptográfico de um gabarito oficial. ChaCha20-Poly1305 é a camada interna de todo perfil de cascata multicamadas neste firmware, então essa verificação está na base de toda a pilha de cifras.
Wycheproof é um corpus de teste lançado pela equipe de segurança do Google (2017). O nome se refere ao Monte Wycheproof na Austrália — frequentemente citado como a menor montanha do mundo — porque o projeto foca em eliminar pequenos obstáculos fatais: estouros de inteiros, casos limite, entradas malformadas e tags de autenticação adulteradas; falhas que aparecem repetidamente em criptografia real implantada. Ele complementa os vetores no estilo RFC: exemplos no estilo RFC 8439 demonstram correção em relação ao AEAD publicado; Wycheproof enfatiza robustez onde implementações historicamente quebram. Neste repositório, o JSON do Wycheproof cobre ChaCha20-Poly1305, AES-GCM, HMAC, HKDF, X25519, Ed25519, RSA e variantes Brainpool ECDH/ECDSA.
BSI TR-03111 é a diretriz técnica para criptografia de curva elíptica publicada pelo Escritório Federal de Segurança da Informação da Alemanha (Bundesamt für Sicherheit in der Informationstechnik). A versão 2.10 é a revisão atual. As curvas Brainpool usadas neste firmware — P256r1 e P384r1 — são especificadas nos padrões BSI, tornando TR-03111 a referência natural para seus vetores de teste. Cada curva tem cobertura ECDH e ECDSA; as assinaturas ECDSA foram adicionalmente verificadas de forma cruzada contra uma implementação Python independente usando a biblioteca cryptography.
Vetores de referência BLAKE3 são o corpus de teste oficial publicado junto com a especificação BLAKE3 por seus autores. Eles cobrem 35 comprimentos de entrada de 0 a 102400 bytes, especificamente escolhidos para exercitar todas as condições de limite internas de chunk e hash em árvore que são invisíveis para testes de entrada curta. Todos os três modos BLAKE3 — hash padrão, hash com chave e derive-key — são cobertos. BLAKE3 é usado em todo este firmware para derivação de chave HKDF e verificações de integridade entre camadas nos perfis de cifra em cascata; a cobertura de limites é importante porque a construção em árvore do BLAKE3 só é ativada acima de 1024 bytes.
O conjunto de testes também é detecção de adulteração para a cadeia de suprimentos. Todas as primitivas criptográficas neste firmware vêm de crates RustCrypto auditados — nenhuma criptografia é implementada na árvore. Como os vetores de conformidade acima são executados contra essas crates em cada cargo test --workspace, qualquer dependência que tenha sido adulterada ou substituída produzirá uma falha de teste de resposta conhecida antes que o código comprometido atinja um sistema implantado. python3 scripts/verify_cascade_kats.py adiciona um segundo caminho independente: uma implementação Python verifica os mesmos valores intermediários no fixture KAT da cascata, de modo que até mesmo uma toolchain Rust comprometida produzindo saída errada é detectada pela verificação cruzada. Esta é uma história de integridade de cadeia de suprimentos significativamente mais forte do que vincular a uma biblioteca C, onde a verificação equivalente de cada operação interna requer significativamente mais esforço e ferramentas especializadas.
Cabe agora ao leitor julgar se essas alegações são falsas ou não.
Você o conecta a uma porta USB. Da perspectiva do host, o firmware pode apresentar modo cripto ou modo camuflagem. No modo cripto, seu computador vê um cartão inteligente: você usa GnuPG ou uma pilha OpenPGP compatível (O que é GnuPG?) da mesma forma que usaria qualquer outro token de segurança de hardware — o token lida com as operações criptográficas sensíveis, de modo que suas chaves privadas nunca existem desprotegidas no seu computador. No modo camuflagem, ele pode ser enumerado como armazenamento removível comum com arquivos de aparência inofensiva, de modo que uma olhada rápida não revele seu verdadeiro papel; veja Camuflagem de armazenamento abaixo.
GnuPG significa GNU Privacy Guard. É a implementação do projeto GNU do OpenPGP, o padrão aberto para gerenciamento de chaves e mensagens criptograficamente protegidas (a mesma família conceitual do PGP, mas especificada em documentos como RFC 4880 e atualizações da comunidade). Normalmente você o executa como o comando gpg no Linux, BSD, macOS ou Windows; muitos utilitários gráficos de e-mail e chave usam isso internamente.
As pessoas usam GnuPG para:
gpg-agent expõe chaves de autenticação de um cartão inteligente ou armazenamento de chaves local.GnuPG e unidades criptografadas (LUKS). O Linux tem uma maneira embutida de criptografar uma unidade ou partição inteira, chamada LUKS. Uma vez que uma unidade é criptografada, parece ruído sem significado para qualquer pessoa sem a chave, então um laptop perdido ou roubado não entrega seus arquivos.
Normalmente, você desbloqueia essa unidade digitando uma senha. O GnuPG permite que você use seu token em vez disso. A ideia é simples: a chave de desbloqueio da unidade está, ela mesma, bloqueada com a chave do seu token. Quando você quer abrir a unidade, o token desembaralha essa chave de desbloqueio para você, mas apenas enquanto o token estiver conectado e você tiver inserido seu PIN. Retire o token e a unidade não pode ser aberta, mesmo no mesmo computador.
Em suma, isso transforma o token em uma chave física para sua unidade criptografada. A configuração (e a adição de uma forma de backup, caso o token seja perdido) é feita com as próprias ferramentas de disco do Linux; o token simplesmente mantém a chave. Se você preferir compartilhar a capacidade de desbloquear uma unidade entre várias pessoas, de modo que nenhuma pessoa sozinha possa fazê-lo, veja Compartilhamento de segredo Shamir e criptografia de unidade.
Por padrão, o GnuPG armazena chaves em ~/.gnupg. Com um cartão inteligente OpenPGP, as chaves privadas sensíveis residem no cartão; scdaemon (parte do conjunto GnuPG) comunica-se via CCID/USB com o cartão enquanto gpg ainda monta pacotes OpenPGP no host.
Para que você pode usá-lo. No modo cripto, o token é destinado ao mesmo trabalho que outros cartões inteligentes OpenPGP: assinar e descriptografar e-mails e arquivos, autenticar (por exemplo, SSH quando você usa gpg-agent normalmente) e manter chaves privadas de longo prazo fora da máquina em que você digita. Organizações podem combinar isso com compartilhamentos Shamir no token para que nenhuma pessoa detenha o segredo inteiro (descrito mais abaixo). GnuPG é o principal alvo de interoperabilidade no host: este firmware implementa a aplicação de cartão OpenPGP sobre CCID, que é dirigida por scdaemon (gpg --card-status, gpg --card-edit e criptografar/assinar/descriptografar normalmente com chaves no cartão). Outros softwares que falam os mesmos protocolos de cartão inteligente também podem funcionar; comandos, slots, algoritmos e limites atuais de integração estão em Compatibilidade OpenPGP e GnuPG. Quando o NFC for implementado no hardware (integração planejada — não no firmware ainda), a mesma classe de dispositivo pode suportar acesso físico: tocar um leitor NFC em uma porta, portão ou painel de fechadura pode participar de uma política que só libera a fechadura após verificações criptográficas (frequentemente combinadas com PIN, biometria ou quorum estilo Shamir, dependendo da implantação). O esboço orientado a PN532 para leitores e painéis está em docs/NFC_PN532_INTEGRATION.md.
Essa é a versão curta. Aqui está o que o torna diferente de outros tokens que você pode ter encontrado.
Camuflagem de armazenamento. O dispositivo pode atuar como armazenamento removível comum, de modo que seu papel real não seja óbvio em uma olhada rápida. Quando você o conecta a um computador típico, ele pode aparecer como uma unidade USB normal ou volume baseado em SD; você pode preencher o sistema de arquivos visível com arquivos cotidianos plausíveis (por exemplo, fotos de férias) para que a navegação casual reforce a impressão de que é apenas armazenamento. Isso frustra a inspeção superficial em uma mesa ou posto de controle. Descobrir que é na verdade um token de segurança geralmente significa desmontar a caixa, não apenas conectá-lo.
Suas chaves permanecem no dispositivo. Quando você assina um e-mail ou descriptografa um arquivo, a chave privada nunca sai do token. O computador envia os dados, o token faz o trabalho, o resultado sai. Um atacante que comprometa seu computador não obtém nada útil.
Sessões passadas permanecem seguras mesmo se o token for roubado. A maioria dos tokens de hardware usa uma chave privada de longo prazo diretamente para acordo de chave. Este gera um novo par de chaves descartável para cada sessão, assina-o com a chave de longo prazo para provar que é genuíno e, em seguida, usa o par descartável para a troca real. Se alguém roubar o token anos depois e de alguma forma extrair a chave de longo prazo, ainda não poderá descriptografar nada das sessões passadas. Essa propriedade é chamada de sigilo de encaminhamento e é incomum em tokens de hardware.
Você pode dividir a chave entre várias pessoas. O token pode dividir a chave de longo prazo em N compartilhamentos, de modo que quaisquer K desses compartilhamentos sejam necessários para reconstruí-la — mas nenhum detentor individual de compartilhamento pode fazer nada sozinho. Isso é chamado de compartilhamento de segredo Shamir. É útil para chaves organizacionais onde nenhuma pessoa deve ter acesso unilateral, ou como uma estratégia de backup onde os compartilhamentos são armazenados em locais separados. Isso também é incomum em tokens de hardware.
A criptografia é em camadas. Em vez de criptografar seus dados com uma única cifra, o token pode executá-los através de múltiplas cifras independentes em sequência — por exemplo ChaCha20, depois Serpent, depois Twofish — cada uma usando uma chave derivada separadamente. Um avanço futuro que quebre uma cifra não quebra as outras. A combinação específica é chamada de perfil de cifra, e você pode escolher entre vários embutidos, dependendo de quanta cautela sua situação exige.
Minha recomendação pessoal é BrainpoolP256r1 + ChaCha20-Poly1305 + BLAKE3. Este é o perfil standard embutido. Ele usa a curva Brainpool P-256 do BSI para acordo de chave efêmera, ChaCha20-Poly1305 para criptografia simétrica e BLAKE3 para derivação de chave e integridade entre camadas. É rápido, bem testado, amigável para bateria (ChaCha20-Poly1305 foi projetado para ser eficiente em hardware sem aceleração AES, reduzindo tempo de CPU e consumo de energia do host; P-256 é a menor das três curvas Brainpool neste firmware), e não depende de nenhuma primitiva projetada pelo NIST. Se você precisar de uma margem maior contra uma futura quebra criptoanalítica de uma única cifra, o perfil conservative adiciona uma camada Serpent-256 por cima.
As escolhas de algoritmos são deliberadas. As cifras usadas — ChaCha20-Poly1305, Serpent, Twofish, Camellia — foram todas projetadas independentemente de órgãos governamentais de padronização. AES e o conjunto NIST são intencionalmente excluídos. Esta é uma escolha consciente para usuários e organizações que desejam independência criptográfica do processo de padronização de um único país. Camellia foi avaliada independentemente pelo projeto NESSIE da UE e pelo programa CRYPTREC do Japão, e é especificada na RFC 3713 e ISO/IEC 18033-3.
Um PIN errado bloqueia você adequadamente. O token conta tentativas de PIN falhadas antes de verificar se o PIN está correto, não depois. Isso significa que uma falha ou perda de energia no meio de uma tentativa não pode ser explorada para redefinir o contador. Após muitas tentativas erradas, o token zera o material sensível.
O que ainda não faz. Ainda não há hardware disponível — este é um firmware em desenvolvimento ativo. Testes de ponta a ponta com hardware USB real e GnuPG são um marco futuro. O transporte NFC e leitores de acesso estilo porta são descritos na documentação como alvos de integração, ainda não como comportamento embarcado. O terceiro fator biométrico descrito na documentação ainda não está implementado. Alguns testes de canal lateral de temporização que exigem hardware real não podem ser concluídos até que um dispositivo exista.
Galdralag pode trabalhar com dois tipos diferentes de chave assimétrica ao mesmo tempo. Elas respondem a perguntas diferentes no dispositivo e no host, e não são intercambiáveis mesmo quando pertencem à mesma pessoa. As seções Compatibilidade OpenPGP e GnuPG, Web of Trust e Festas de Assinatura de Chaves, Metadados de contato Galdra e Comparação de metadados (GnuPG vs Galdra) descrevem cada pilha em mais detalhes; aqui está como elas diferem em termos cotidianos.
Uma chave OpenPGP, no sentido que o GnuPG gera e usa, é um pacote estruturado, não um número público simples. Ela agrupa a chave primária, subchaves para assinatura e criptografia, e um ou mais User IDs — geralmente um nome de exibição e um endereço de e-mail como Alice Example <[email protected]>. Outras pessoas podem assinar esses User IDs para dizer que acreditam que a alegação de identidade é genuína; esse grafo social é a base da web de confiança descrita em Web of Trust e Festas de Assinatura de Chaves mais adiante neste README. Quando Galdralag atua como um cartão inteligente OpenPGP, ele mantém o material da chave privada no chip e realiza assinatura e descriptografia lá. A chave pública, os User IDs e as assinaturas de outros residem no host e são gerenciados pelo GnuPG da maneira usual. O token não altera o formato da mensagem OpenPGP no fio; o GnuPG o trata como qualquer outro cartão OpenPGP.
Uma chave Galdra é um par de chaves assimétricas simples — Ed25519, X25519 ou uma das curvas Brainpool ou NIST que o firmware suporta. Os bytes da chave em si não carregam nenhuma alegação de identidade: sem pacotes User ID, sem e-mail incorporado, sem assinaturas web-of-trust anexadas à estrutura da chave. A identidade de uma chave Galdra vem do registro de contato armazenado ao lado dela no banco de dados SQLite do host e na loja de contatos no chip, vinculado à chave por sua impressão digital.
A tabela abaixo compara metadados de identidade e contato campo por campo. As colunas OpenPGP / GnuPG descrevem o que você obtém de um certificado normal e User ID (mais linhas de contato opcionais no lado do host em Galdra quando você armazena uma chave pública OpenPGP no mesmo diretório). As colunas Chave Galdra descrevem campos estruturados auxiliares para contatos operacionais (detalhes completos do host e do chip em Metadados de contato Galdra). Um traço significa que aquela pilha não possui um campo padrão e separado para esse item.
O OpenPGP coloca nome e e-mail em uma única string User ID; não fornece campos separados e legíveis por máquina para indicativo, DMR ou postal. Galdra mantém esses como colunas nomeadas para que equipes de rádio e operações possam pesquisá-los e exibi-los sem analisar texto de certificado.
Aplicação de cartão 3.4.1, CCID e fluxos de trabalho GnuPG: docs/OPENPGP_CARD.md e Compatibilidade OpenPGP e GnuPG.
Tokens atualizados de firmware que ofereciam BrainpoolP512r1 ainda podem retornar atributos P-512 no GET DATA; operações GnuPG nesses slots falham então com erros genéricos de cartão. Execute galdra device status (ou veja docs/OPENPGP_CARD.md) para identificar slots obsoletos; histórico de remoção está em CHANGELOG.md.
A divisão existe porque as informações de identidade que importam nas comunidades que Galdralag visa — indicativo, DMR ID, afiliação de rede de rádio — não têm um lar natural em um User ID OpenPGP. Um User ID é feito para nome e e-mail. Escrever algo como LA5XYZ <[email protected]> DMR:2345678 em uma string User ID é informal, não estruturado e não legível por máquina de forma padrão. As chaves Galdra mantêm o material criptográfico limpo e colocam a identidade operacional em um formato de registro que a ferramenta do host e o armazenamento no chip entendem nativamente.
Na prática, um único dispositivo pode conter ambos os tipos de chave sem conflito. A aplicação de cartão OpenPGP atende ao GnuPG através dos slots padrão SIG, DEC e AUT. A loja de contatos mantém chaves Galdra para trabalho operacional — por exemplo, criptografar para um contato de rádio por indicativo, verificar uma mensagem contra um ID de assinante DMR ou procurar um colega pelo número do crachá. Os dois caminhos não interferem um no outro.Se alguém possui um certificado OpenPGP gerenciado pelo GnuPG no host e uma chave Galdra no armazenamento de contatos no chip, essas são duas chaves separadas com duas impressões digitais separadas. A impressão digital Galdra — prefixada com G: e derivada com BLAKE3 dos bytes brutos da chave pública — não é o mesmo valor que a impressão digital OpenPGP v4 do certificado GnuPG dessa pessoa. A ferramenta do host e o dispositivo as tratam como identidades independentes. Não presuma que uma impressão digital implica a outra sem verificar ambas.
Nenhum tipo de chave atesta automaticamente os rótulos ao seu redor. Um User ID OpenPGP é autoafirmado até que outra pessoa o assine. Um indicativo ou campo DMR em um registro de contato Galdra é tão confiável quanto sua fonte — uma busca em servidor de chaves, uma entrada manual, ou uma verificação fora de banda que você mesmo realizou. Os rótulos de proveniência (SelfAttested, HostVerified, RegistrySync, OobVerified) registram como um campo chegou; eles não substituem o trabalho de realmente verificar a identidade que lhe interessa.
Este firmware é escrito em Rust, uma linguagem de programação de sistemas projetada para ser tão rápida e de baixo nível quanto C ou C++, mas com uma abordagem fundamentalmente diferente para segurança.
Uma grande parcela de bugs relevantes para segurança em bases de código da indústria vem de insegurança de memória (estouros de buffer, uso após liberação, desreferências nulas e similares). O MSRC da Microsoft tem relatado repetidamente que aproximadamente 70% dos CVEs tratados em seus próprios produtos se enquadram nesta categoria; a equipe do Chrome publicou proporções semelhantes para o Chrome. Esses números descrevem os produtos desses fornecedores, não uma lei universal para todo firmware, mas ilustram por que linguagens com segurança de memória são importantes.
Em Rust seguro (o padrão), o verificador de empréstimos (borrow checker) elimina condições de corrida e os erros de memória usuais de comportamento indefinido em tempo de compilação sem depender de coleta de lixo. Rust inseguro (unsafe) e FFI para C ainda podem introduzir bugs de memória; eles devem ser mantidos pequenos e revisados.
A verificação de limites do Rust em slices e suas regras de propriedade reduzem várias classes de modos de falha comuns em código embarcado C/C++:
unsafe devem ser explícitos; MMIO e ponteiros brutos para registradores ficam lá, para que revisores possam usar grep na superfície de auditoria (unsafe não torna MMIO incorreto impossível, apenas mais fácil de localizar).Rust não impede por si só bugs lógicos como um loop apertado que desgasta a flash, ou escolher valores de registradores errados. Esses continuam sendo preocupações de engenharia e revisão.
Esta base de código aplica padrões comuns do Rust para segredos; eles não são automáticos para todo tipo:
zeroize::Zeroize / ZeroizeOnDrop limpam buffers ao serem descartados (drop); os chamadores optam por isso.subtle::ConstantTimeEq (e similares) onde o timing importa — == comum não é magicamente de tempo constante.Copy em wrappers de segredos reduz duplicação acidental; separação de domínios usa tipos distintos e rótulos HKDF (Política de dependência criptográfica).catch_unwind ou abort onde sua plataforma exigir garantias mais fortes.unsafe deve ser explicitado no código fonte, o que restringe a revisão manual. Dependências: a política criptográfica deste projeto favorece crates Rust auditados (RustCrypto e outros); veja a tabela em Política de dependência criptográfica — nem toda dependência é de um único projeto guarda-chuva.
Rust não remove deadlocks (ex.: locks Mutex mal ordenados), bugs lógicos, protocolos incorretos, desgaste da flash devido a loops ruins, ataques físicos (glitching, análise de potência), ou riscos de uma construção correta da imagem errada. Também não garante execução em tempo constante em todo hardware sem codificação cuidadosa. Essas áreas dependem de projeto, revisão, testes e das práticas de criptografia e cadeia de suprimentos do projeto descritas em outras partes deste README.
Além da linguagem, este repositório utiliza testes unitários, testes de integração, harnesses de temporização dudect e alvos libFuzzer (cargo-fuzz). Resumos e matrizes estão em Resultados de testes; os metadados de execução registrados começam em docs/TEST_RESULTS.md#run-metadata. Testes aprovados não comprovam prontidão para produção ou ausência de vulnerabilidades — eles reduzem o risco. Você decide se executar builds ou testes é aceitável para seu ambiente; uma máquina virtual é opcional, mas limita o raio de explosão em sua máquina.
Qualquer plataforma VM importante é adequada — VirtualBox (gratuito, código aberto), QEMU (gratuito, código aberto, linha de comando), ou VMware. Um convidado Linux é recomendado, pois o ambiente de compilação é melhor suportado lá.
Início rápido com QEMU e Ubuntu:```bash
sudo apt install qemu-system-x86 # Debian/Ubuntu host
brew install qemu # macOS host
qemu-system-x86_64 -m 2G -cdrom ubuntu-24.04-live-server-amd64.iso
Dentro da VM, as instruções padrão de compilação se aplicam. A VM pode ser **snapshotted** antes de cada experimento e **revertida** de forma limpa se algo der errado.
### Avaliação e implantação de riscos
**Em última análise, se este firmware é seguro para implantar no seu ambiente é uma decisão que só você pode tomar**, com base na sua própria avaliação de riscos, na sensibilidade do que está protegendo e se você opta por aguardar uma auditoria independente de terceiros antes da implantação. Este projeto visa fornecer todas as informações necessárias para tomar essa decisão por conta própria.
Uma lista estruturada de ativos, ameaças **T1–T14**, não-metas explícitas e lacunas de verificação Q2 está em **[docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/THREAT_MODEL.md)**.
---
## Sobre o nome
**Galdr** é a prática do nórdico antigo de magia falada ou cantada: encantamentos usados para amarrar, proteger ou revelar. Nas sagas, nomeia o ato de lançar o feitiço em si, não apenas as palavras. Às vezes também usado para ativar inscrições rúnicas mágicas, como na [haste de lança Kragehul I](https://en.wikipedia.org/wiki/Kragehul_I), no [amuleto de Lindholm](https://en.wikipedia.org/wiki/Lindholm_amulet), no [bracelete de Vadstena](https://en.wikipedia.org/wiki/Vadstena_bracteate) e outros achados do Futhark Antigo.
**Galdralag** é a forma métrica usada para galdr: verso estruturado, preciso e sujeito a regras, no qual o padrão é parte da força do feitiço. O sufixo *lag* é semelhante a "lei" ou "padrão".
**Runas** eram literalmente conhecimento secreto e codificado — o uso xamânico era conhecido apenas por aqueles que entendiam.
---
## Documentação
**Glossário:** [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GLOSSARY.md) — termos explicados em **linguagem simples** (ordenados A–Z). Comece aqui se o README ou outros docs parecerem com muito jargão.
**Depuração:** [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/DEBUG_INSTRUCTIONS.md) — backtraces, estreitamento de `cargo test`, atalhos `xtask`, verificações triplas do firmware, fuzzing e o que coletar antes de relatar um problema.
**Assistentes de IA (Claude, Cursor):** [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/CLAUDE.md) — instruções do projeto para agentes de codificação. Regras específicas do Cursor: [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/.cursor/rules/).
**Navegar por todos os arquivos:** [github.com/Supermagnum/Galdralag-firmware — `docs/`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/docs)
**Hardware (dongle USB e relacionados):** Duas árvores KiCad: [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-files-usb/) — `dabao_v3c` (token USB-A **sem** micro-SD); e [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/) — `dabao_v3c_sdcard` (mesmo layout base **com** suporte para micro-SD), gerbers, BOM, saídas de produção e [docs de pinagem](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/docs/pinout/README.md). O layout da PCB do dongle USB-A (token mínimo vs formato Pico para avaliação) é descrito em [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md).
| Documento | Descrição |
|-----------|-----------|
| [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-files-usb/) | Projeto KiCad **dongle USB** `dabao_v3c` (sem micro-SD); gerbers, BOM, saídas de produção; complementa [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md) |
| [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/) | Projeto KiCad **dongle USB** `dabao_v3c_sdcard` (suporte micro-SD); gerbers, BOM, pinagem em [docs/pinout](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/Hardware/kicad-sd-card/docs/pinout/README.md); complementa [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md) |
| [docs/CODE_MAP.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CODE_MAP.md) | **Índice de funções e módulos** do workspace (por arquivo `pub fn` / tipos com âncoras de linha) |
| [docs/CRATE_DEPENDENCIES.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CRATE_DEPENDENCIES.md) | Crates Rust **upstream vs projeto** e como elas dependem umas das outras |
| [docs/API_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/API_REFERENCE.md) | Mapa de código + **anexo** para IETF/I-D/GnuPG/Sequoia: construção Shamir GF(256), blindagem GALDRA SHARE, formato de fio ECDH efêmero, rótulos HKDF, pré-imagens; rotas `galdrad`; dicas de rustdoc |
| [docs/ARCHITECTURE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/ARCHITECTURE.md) | Arquitetura de firmware de alto nível e subsistemas principais |
| [docs/AUDIT_LOG.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/AUDIT_LOG.md) | Registros de auditoria de perfil (`cipher-profile`), hook OpenPGP `OpenPgpAudit`; **nenhum** log RRAM append-only implementado ainda |
| [docs/BIOMETRIC_API.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/BIOMETRIC_API.md) | Pré-portão biométrico: arquitetura, formato de fio, layout do cofre; integração parcialmente implementada |
| [docs/BIOMETRIC_DEVICE_GUIDE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/BIOMETRIC_DEVICE_GUIDE.md) | Como adicionar suporte para um novo backend de hardware biométrico |
| [docs/BIOMETRIC_TESTING.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/BIOMETRIC_TESTING.md) | Metodologia de teste: métricas PAD ISO/IEC 30107-3, conjuntos de dados, como executar |
| [docs/FINGERVEIN_DEVICE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/FINGERVEIN_DEVICE.md) | Dispositivo de veias do dedo aberto ESP32-CAM: hardware, esboço de protocolo, vivacidade |
| [docs/SWEET_PLATFORM_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/SWEET_PLATFORM_INTEGRATION.md) | Scanner de mão da plataforma sweet: hardware, integração, vivacidade, conjunto de dados |
| [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md) | Ferramentas do host (`galdra`, `galdrad`, `galdra-gtk`): fluxos de trabalho, provisionamento, política de PIN, comportamento operacional |
| [Supermagnum/Fulla](https://github.com/Supermagnum/Fulla) | **Fulla**: registro de chaves públicas OpenPGP orientado a WoT (repositório e implementação do servidor). **Nenhuma instância de registro público está em execução ainda**; uma está planejada. **`galdra keyserver push`** / **`galdra keyserver fetch`** e a configuração opcional **`[keyserver]`** visam este ecossistema — veja também [Web of Trust e Festas de Assinatura de Chaves](#web-of-trust-e-festas-de-assinatura-de-chaves). Notas de design suplementares permanecem em [docs/server.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/server.md). |
| [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GLOSSARY.md) | **Glossário em linguagem simples** (A–Z) para leitores não técnicos; detalhes técnicos permanecem em documentos vinculados |
| [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/CLAUDE.md) | Instruções para **Claude** / agentes de codificação de IA; aponta para [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/.cursor/rules/) para **Cursor** |
| [docs/GALDRALAG_DEV_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRALAG_DEV_REFERENCE.md) | Cadeia de ferramentas, comandos `xtask`, pontos de entrada de fuzzing e teste criptográfico |
| [docs/dev-ref.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/dev-ref.md) | Layout do workspace, crates, traits HAL, comportamento USB/PSRAM, invariantes de segurança |
| [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/DEBUG_INSTRUCTIONS.md) | Depuração: `RUST_BACKTRACE`, compilações verbosas, testes com escopo, receitas `xtask`, verificações de destino embarcado, dicas de fuzzing, verificações de host OpenPGP |
| [docs/KEY_LIFECYCLE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/KEY_LIFECYCLE.md) | Geração de chaves, importação, política de exportação, rotação, zeragem, Shamir (conforme refletido em `vault` / OpenPGP) |
| [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/OPENPGP_CARD.md) | Aplicação de cartão OpenPGP, configuração de host GnuPG/CCID, slots de chave, algoritmos, udev |
| [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CIPHER_PROFILES.md) | Sistema de perfil de cifra e configuração |
| [docs/CIPHER_PROFILE_SECURITY.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CIPHER_PROFILE_SECURITY.md) | Considerações de segurança: identificadores de perfil em texto claro, análise de tráfego, justificativa do wrapper externo BrainpoolP384r1, identificadores criptografados, propriedade de curinga |
| [docs/CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CESS_CONFORMANCE.md) | Alinhamento [CESS](https://github.com/Supermagnum/CESS/tree/main): layout de fio Modo A, `suite_id` da [ALGORITHM-REGISTRY.md — tabela de consulta](https://github.com/Supermagnum/CESS/blob/main/ALGORITHM-REGISTRY.md#cipher-suite-identifier-lookup-table), registro de desvio (AES/SHA-2 retidos vs CESS-CORE), roteiro |
| [crates/cess](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/crates/cess) | Modo A CESS: HKDF-BLAKE3 (`derive_k_outer`, `hkdf_blake3`), selo/abertura externa ChaCha, layout `suite_id \|\| inner_blob`; veja [CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/CESS_CONFORMANCE.md) |
| [docs/EPHEMERAL_SESSION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/EPHEMERAL_SESSION.md) | Protocolo de sessão ECDH efêmero autenticado |
| [Supermagnum/CESS](https://github.com/Supermagnum/CESS) | **CESS** (*Cryptologically Enchanted Shamir's Secret*) — especificação aberta (texto normativo e vetores de teste) para compartilhamento secreto de limiar com criptografia autenticada, encapsulamento de compartilhamento baseado em senha e troca de chaves híbrida pós-quântica opcional; separado deste firmware, mas no mesmo espaço de design que Shamir e perfis de cifra aqui |
| [docs/PQ_SIGNATURES.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/PQ_SIGNATURES.md) | Assinaturas com estado pós-quânticas (XMSS, LMS/HSS), ativação por recurso |
| [docs/Psram.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/Psram.md) | Volume isca microSD opcional e comportamento relacionado |
| [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/RRAM_LAYOUT.md) | RRAM no chip de **4.194.304 bytes**: deslocamentos do cofre a partir da fonte, mapeamento HAL, notas de desgaste/zeragem |
| [docs/TEST_RESULTS.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/TEST_RESULTS.md#run-metadata) | Abre em **Metadados de execução**; resumo do pipeline, vetores, dudect, cargo-fuzz ([Seção 6](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/TEST_RESULTS.md#6-cargo-fuzz-libfuzzer)), ciclo de vida da chave |
| [docs/THREE_FACTOR_AUTH.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/THREE_FACTOR_AUTH.md) | Token + PIN + biométrico opcional: o que este repositório implementa vs espaço reservado; esboço de ameaça |
| [docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/THREAT_MODEL.md) | Modelo de ameaça: ativos, ameaças T1–T14, o que é e não é defendido, itens não verificados pendentes de hardware Q2, status de auditoria |
| [docs/PERFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/PERFORMANCE.md) | Notas de desempenho |
| [docs/HARDWARE_BRINGUP_TEST_PLAN.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_BRINGUP_TEST_PLAN.md) | Inicialização do primeiro hardware Q2: enumeração CCID, `gpg --card-status`, USB CDC `galdralag-provision` para PINs de primeira inicialização, depois `gpg --card-edit` / testes smoke criptográficos |
| [docs/HARDWARE_VERIFICATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_VERIFICATION.md) | Zeragem de hardware: simulação vs verificação de silício |
| [docs/HARDWARE_TEST.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_TEST.md) | Notas de teste orientadas a hardware |
| [docs/NFC_PN532_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/NFC_PN532_INTEGRATION.md) | PN532 / NFC: libnfc, opções Rust, porta passiva vs painel USB, quórum com Shamir e PIN |
| [docs/SDMMC_STORAGE_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/SDMMC_STORAGE_INTEGRATION.md) | `embedded-sdmmc` + microSD SPI como armazenamento em massa opcional; alternativa BOM para PSRAM |
| [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/USB_DONGLE_PCB.md) | Como fazer uma PCB de dongle USB-A a partir da referência Dabao: avaliação em formato Pico é para inicialização do firmware; isto remove o cabeçalho GPIO para um token mínimo; KiCad, FreeCAD, 5 V / 500 mA vs USB-C PD, roteamento QSPI PSRAM |
Os mesmos caminhos são resolvidos no GitHub em [`tree/main/docs`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/docs) e [`tree/main/Hardware`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/Hardware).
---
## Compatibilidade OpenPGP e GnuPG
O firmware implementa a **aplicação de cartão OpenPGP** (documentada como versão **3.4.1** em [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/OPENPGP_CARD.md)). Essa é a mesma classe de dispositivo que o GnuPG utiliza para **cartões inteligentes OpenPGP** via **CCID/USB**: o host precisa de uma pilha normal de cartão inteligente (`pcscd`, drivers `ccid`, `scdaemon` do GnuPG). **Nenhum driver criptográfico personalizado no lado do host** é necessário além do que você usaria para qualquer cartão OpenPGP.
**O que isso permite no host (uma vez que o dispositivo esteja visível como um leitor CCID):**
| Área | Notas |
|------|--------|
| **Fluxos de trabalho GnuPG** | `gpg --card-status`, `gpg --card-edit`, criptografar/descriptografar e assinar usando chaves no cartão |
| **SSH** | `gpg-agent` com `enable-ssh-support` e a configuração usual `SSH_AUTH_SOCK` |
| **Correio e arquivos** | Clientes que usam GnuPG (ex.: Thunderbird, Evolution, Kleopatra) e criptografia padrão de arquivos `gpg` |
| **Outras ferramentas** | Qualquer coisa que fale com cartão OpenPGP + CCID da mesma forma que o GnuPG |
**Slots de chave (padrões típicos):** **SIG** (assinatura), **DEC** (descriptografia / ECDH), **AUT** (autenticação, ex. SSH). Os algoritmos são selecionáveis por slot (curvas Brainpool, NIST P-256/P-384, Ed25519 / X25519, RSA). A tabela completa e o comportamento de `key-attr` estão em [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/OPENPGP_CARD.md).
**Não coberto pelo cartão OpenPGP / GnuPG aqui:** **WebAuthn / FIDO2** é um protocolo diferente e está fora do escopo desta aplicação de cartão (veja o mesmo documento).
**Cartão OpenPGP vs. mensagens OpenPGP:** A especificação do **cartão** define como o token expõe PINs, slots de chave e operações no cartão via CCID. **GnuPG** usa isso através do `scdaemon`. O **formato de mensagem OpenPGP** para arquivos e correio (RFC 4880 e sucessores) é uma camada do **lado do host**: o cartão fornece chaves; o GnuPG ainda aplica o formato de mensagem no PC. Nem a especificação do cartão nem a RFC 4880 definem **divisão Shamir**, **sessões ECDH efêmeras** ou **perfis de cifra** — essas são características [específicas do firmware](#padrões-vs-características-específicas-do-firmware).
**Status de integração:** A lógica OpenPGP e CCID reside em **`usb-personality`**, **`baochip-openpgp`** e no serviço **Xous** **`usb-bao1x`** (veja **xous-core**). O opcional **`galdralag-service`** (`services/galdralag`) é executado como um processo Xous separado, conecta-se a **`usb-bao1x`** para IPC **CCID** e faz a ponte dos dados de provisionamento **PDDB** para **RRAM**; compilação e registro **`baosec`**: [services/galdralag/README.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/services/galdralag/README.md) e **`cargo run -p xtask -- build-and-register`**. Layout de memória: [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/RRAM_LAYOUT.md). **GnuPG de ponta a ponta em hardware real** ainda precisa de uma imagem Xous completa (com **`ccid-openpgp`**), uma pilha CCID de host funcional (`pcscd`, driver) e itens em [Limitações conhecidas / trabalho em aberto](#limitações-conhecidas--trabalho-em-aberto) abordados onde se aplicam ao seu alvo de envio.
## Sessão do token e exportação de chave
**Desconexão física (desconectar):** O host perde o dispositivo USB; qualquer operação em andamento falha até que o token seja conectado novamente e reenumerado. No dispositivo, a **sessão do cartão** OpenPGP é limpa: o **estado de verificação PIN** não sobrevive a desligamento ou remoção, portanto **assinatura, descriptografia e outras operações protegidas exigem VERIFY PIN novamente** após reconexão, como em outros cartões inteligentes OpenPGP. **O material da chave privada permanece armazenado no token** no armazenamento selado do cofre; desconectar não o apaga a menos que um caminho separado de **zeragem** ou limpeza seja executado.
**O que pode deixar o dispositivo:** Por design, **apenas material de chave pública** tem permissão para cruzar o link USB (por exemplo, pacotes de chave **pública** OpenPGP e dados relacionados que a especificação do cartão expõe ao host). Chaves **privadas**, escalares secretos brutos e blobs de chave selados **não** saem do dispositivo através dos caminhos normais do firmware; as operações de chave privada são executadas **no token**. O host recebe **resultados criptográficos** (assinaturas, texto simples descriptografado para fluxos de trabalho de descriptografia assistida por cartão) onde os comandos padrão exigem, não uma cópia portátil da chave privada.
**Importação de chaves para o dispositivo:** Também é possível **importar chaves públicas** para o token (por exemplo, âncoras de confiança, certificados de pares ou pacotes públicos OpenPGP para verificação no dispositivo). O **cofre** do firmware fornece **slots de chave pública** para material não secreto (`crates/vault/src/public_key_vault.rs`). As ferramentas do host para carregar esses slots são descritas em [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md) à medida que a integração amadurece.
---
## Web of Trust e Festas de Assinatura de Chaves
OpenPGP e **GnuPG** usam um modelo de confiança descentralizado — a **web of trust** — para ajudar a verificar quem possui quais chaves e se deve confiar em uma determinada **chave pública**. Esse modelo é inteiramente do **lado do host**. Onde atestações apoiadas por chip, como [eID alemão e Governikus](#eid-alemão-e-governikus-como-âncora-de-confiança-para-chaves-públicas), não estão disponíveis ou são inadequadas, é a alternativa descentralizada usual (**festas de assinatura de chaves**, assinaturas em certificados); onde **estão** disponíveis, ambas as abordagens podem coexistir como caminhos complementares.
**Impressão digital Galdralag (`G:`):** Para fluxos de trabalho de verificação presencial, **Galdra** pode mostrar uma impressão digital **vinculada ao dispositivo** derivada da chave pública **SIG** do token (**BLAKE3-160**, prefixo `G:`). **Não** é uma impressão digital de certificado OpenPGP v4. Está **apenas** disponível quando o **perfil de cifra** ativo tem **`ephemeral_ecdh: false`**; os perfis integrados padrão têm **`ephemeral_ecdh: true`**, então você normalmente adiciona um perfil de usuário com **`galdra profile add ... --no-ephemeral-ecdh`** para fluxos de trabalho que precisam desse identificador junto com a assinatura do host no estilo **WoT**. Definição em linguagem simples e especificação de formato: [Impressão digital Galdralag](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GLOSSARY.md#g). Ciclo de vida, política de rotação e o gate ECDH efêmero: [KEY_LIFECYCLE.md — Impressão digital Galdralag](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/KEY_LIFECYCLE.md#galdralag-fingerprint-host).
### Obtendo sua impressão digital Galdralag
O host imprime uma string que **sempre começa com `G:`** (BLAKE3-160 sobre os bytes da chave pública SIG, **40 caracteres hexadecimais minúsculos** após o prefixo na forma canônica).
1. Instale **[Galdra](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md)** no host e certifique-se de que **PC/SC** funcione (**`pcscd`**, **`libpcsclite`**) para que a ferramenta possa falar CCID com o token (veja [Compilar e instalar ferramentas do host](#compilar-e-instalar-ferramentas-do-host-galdra-galdrad-galdra-gtk)).
2. Conecte o token (desbloqueie se seu fluxo de trabalho exigir).
3. Selecione um **perfil de cifra** com **`ephemeral_ecdh: false`**. Confirme com **`galdra profile show <nome>`** (`ephemeral_ecdh: off`). O nome de perfil padrão **`standard`** geralmente tem **`ephemeral_ecdh: on`**; crie um com **`galdra profile add <nome> ... --no-ephemeral-ecdh`** se necessário.
4. Execute:```bash
galdra identity fingerprint
# If you use a non-default profile:
galdra identity fingerprint --profile <name>
Saída legível por máquina: galdra --emit json identity fingerprint (opcionalmente --profile <nome>).
Implementações compatíveis com o OpenPGP incluem um esquema de verificação de certificados para ajudar a verificar a propriedade da chave; a sua operação tem sido chamada de rede de confiança. Os certificados OpenPGP (uma ou mais chaves públicas mais material de proprietário/ID do utilizador) podem ser assinados digitalmente por outros utilizadores que, ao fazê-lo, endossam a associação entre essa chave pública e a pessoa ou entidade nomeada no certificado.
gpg --full-generate-key no anfitrião, ou transportada num token compatível com OpenPGP).Uma festa de assinatura de chaves é um encontro presencial onde os participantes trocam impressões digitais de chave e verificam a identidade uns dos outros antes de assinar certificados mais tarde.
Características típicas:
Isso resulta num grafo social: se Alice confia em Bob e Bob assinou a chave do Charlie, Alice pode optar por confiar na chave do Charlie dependendo da profundidade da confiança e da política.
Por que esses eventos são importantes:
As festas geralmente evitam computadores durante a troca de identidade para que os atacantes tenham menos oportunidades de inserir chaves trocadas ou malware em máquinas partilhadas.
Antes do evento. Calcule e registe a sua impressão digital (um resumo derivado de hash da chave pública — suficientemente curto para comparar de forma fiável). Não confie na troca de chaves completas em papel nesta fase, a menos que os organizadores especifiquem o contrário.```bash
gpg --fingerprint YOUR_KEY_ID
Traga a impressão digital em papel ou outro meio durável (exemplo de formato: `ABCD 1234 EFGH 5678 90AB CDEF 1234 5678 90AB CDEF`).
**No evento (apenas impressões digitais).** Troque **impressões digitais**, verifique as identificações e anote quais impressões pertencem a qual pessoa verificada. Confirme que a identidade reivindicada de cada participante corresponde aos documentos verificados.
**Após o evento.** Obtenha as **chaves públicas** completas de **servidores de chaves** ou distribuição direta; confirme que as chaves descarregadas correspondem às **impressões digitais** registadas em papel; **assine** as chaves que verificou; opcionalmente **envie** as assinaturas para que outros possam usá-las.
### Impressões digitais em vez de chaves completas no evento
- **Segurança operacional.** Mantém os ataques de substituição ligados a impressões digitais verificadas, em vez de confiar em máquinas arbitrárias durante o evento.
- **Simplicidade.** As impressões digitais cabem no papel e são rápidas de ler em voz alta ou comparar.
- **Verificação.** Após o download, recalcular a impressão digital verifica a integridade de ponta a ponta.
### Servidores de chaves
**Servidores de chaves** são repositórios em rede que armazenam e replicam chaves OpenPGP **públicas** (e atualizações como assinaturas e revogações). Eles tornam as chaves localizáveis por **Identificador de Utilizador**, **ID da chave** ou **impressão digital** e sustentam a distribuição em larga escala para a teia de confiança.
Como se comportam em princípio:
- **Replicação distribuída.** Enviar para um servidor que participa de uma malha de sincronização geralmente propaga para pares (os pools clássicos estilo **SKS** funcionavam assim).
- **Sincronização.** Novas chaves, assinaturas e certificados de revogação se espalham de acordo com a política e conectividade de cada servidor.
- **Acesso de leitura público.** Apenas material **público** é destinado à publicação; **chaves privadas** nunca devem ser enviadas.
**Privacidade.** As chaves publicadas expõem **Identificadores de Utilizador** (geralmente incluindo endereços de email). Trate os envios como **públicos e duradouros** em muitos servidores; envie **certificados de revogação** quando uma chave precisar ser retirada. A política varia por operador ([keys.openpgp.org](https://keys.openpgp.org/) difere dos pools legados).
**Topologia de pares.** Gráficos de relações entre servidores aparecem em [spider.pgpkeys.eu/graphs/](https://spider.pgpkeys.eu/graphs/); listagens de pares orientadas a SKS em [spider.pgpkeys.eu/sks-peers](https://spider.pgpkeys.eu/sks-peers).
### Utilizando servidores de chaves```bash
# Upload your signed key (after local signing)
gpg --send-keys YOUR_KEY_ID
# Search by mail or name (behaviour depends on keyserver configured in gpg.conf)
gpg --search-keys [email protected]
# Refresh imported keys from configured keyservers
gpg --refresh-keys
| Servidor | Notas |
|---|---|
| keys.openpgp.org | Amplamente utilizado; verificação orientada por consentimento para User IDs vinculados a e-mail |
| pgp.mit.edu | Servidor hospedado pelo MIT historicamente ligado às malhas da era SKS |
| pool.sks-keyservers.net | Nome de host legado do pool associado ao antigo ecossistema SKS; conectividade hoje varia |
gpg --refresh-keys periodicamente para que revogações e novas assinaturas se propaguem localmente.ephemeral_ecdh: false com galdra profile show <name>.Para comportamento autoritativo de gpg, modelos de confiança e opções de distribuição, consulte o manual do GnuPG e a documentação upstream.
O projeto Fulla (Supermagnum/Fulla no GitHub) hospeda o trabalho do servidor de registro alinhado à WoT: implementação e especificação em evolução para armazenar chaves públicas de contribuidores mais rótulos opcionais de rádio amador, dicas postais, organisation (grafia JSON), role, note, badge_number, phone_number e colunas relacionadas alinhadas com metadados de contato Galdra. galdra keyserver push submete JSON POST /api/v1/keys (incluindo armored_public_key, email e esses campos opcionais quando você passa flags CLI); galdra keyserver fetch e a estrofe de configuração [keyserver] estão implementadas em / contra essa direção. ; espera-se um serviço operado publicamente no futuro. Prosa de design histórico adicional reside em .
Diferentes partes deste projeto se alinham com diferentes padrões. Interoperabilidade GnuPG é limitada ao que a aplicação de cartão OpenPGP e CCID definem. Outras funcionalidades são implementadas no firmware (e às vezes nas ferramentas host Galdra) mas não são algo que você possa invocar através de fluxos de trabalho padrão de cartão gpg.
Para comportamento diário do cartão, confie em docs/OPENPGP_CARD.md. Para funcionalidades apenas no cofre ou exclusivas do token, use o firmware deste repositório e a documentação da ferramenta Galdra.
As pilhas OpenPGP card e GnuPG não definem o Compartilhamento de Segredo de Shamir (SSS) para chaves ou para desbloqueio de disco. SSS ainda é útil junto com criptografia normal: ele quase nunca substitui a cifra simétrica no disco — ele protege o pequeno segredo (chave mestre ou frase secreta) que desbloqueia essa criptografia.
Padrão (sempre a mesma ideia):
1. LUKS (Linux) e SSS externo
LUKS criptografa o volume com uma chave mestre. Você pode extrair essa chave (ou um segredo de slot de chave, dependendo do seu procedimento), dividi-la com uma ferramenta SSS e armazenar partes separadamente. No momento do desbloqueio, combine K partes, reconstrua o material de chave e forneça-o ao cryptsetup (consulte a documentação da sua distribuição; manipulação incorreta de chaves pode bloquear o acesso).
Exemplo de forma usando os utilitários ssss ("Shamir's Secret Sharing Scheme") (nomes e empacotamento variam por SO):```bash
ssss-split -t 3 -n 5 < luks_master.key
ssss-combine -t 3 | cryptsetup luksOpen /dev/sdX vault
**2. HashiCorp Vault**
[Vault](https://www.hashicorp.com/products/vault) usa Shamir para **unseal**: a chave de criptografia de armazenamento é dividida na inicialização (ex.: 3 de 5 operadores cada um possui uma parte). Após a reinicialização, **K** partes devem ser inseridas para fazer o unseal. Mesmo padrão **K-de-N em um segredo mestre** que o LUKS, aplicado a um mecanismo de segredos em vez de um dispositivo de bloco.
**3. Firmware Galdralag (`vsss-rs`)**
Este repositório usa [`vsss-rs`](https://crates.io/crates/vsss-rs) (ecossistema RustCrypto) para Shamir em dispositivo. A mesma **camada** se aplica se você alinhar com criptografia em massa:
- Gere uma chave mestra aleatória de 256 bits (ou apropriada).
- Criptografe a unidade ou armazenamento em massa com **AES-GCM** ou **ChaCha20-Poly1305** usando essa chave (isso corresponde às crate simétricas auditadas do workspace).
- Use `vsss-rs` para dividir a chave mestra em **N** partes com limite **K**.
- Armazene partes em slots de vault, outros dispositivos, ou com detentores de chave.
- Na inicialização ou recuperação, colete **K** partes, reconstrua, então use **HKDF** (ou sua política) para subchaves separadas por domínio, se necessário.
**4. VeraCrypt**
VeraCrypt não implementa SSS internamente. O mesmo padrão **externo** se aplica: divida a **frase secreta ou material do arquivo de chave** com uma ferramenta SSS; não tente fazer Shamir-split do texto cifrado do volume.
### Padrão híbrido (dados grandes)
SSS é para **segredos pequenos** (tamanho da chave). Você **não** aplica Shamir a texto cifrado de vários gigabytes. A estratificação usual:```text
[Drive data]
encrypted by
[Symmetric master key, e.g. 32-byte AES-256]
split by SSS into
[Share 1] [Share 2] ... [Share N]
(each share may be wrapped with a recipient's PGP key, HSM, or offline media)
Isso está alinhado com o que este projeto já utiliza: aes-gcm / chacha20poly1305 para dados em repouso, vsss-rs para dividir o segredo mestre, hkdf para derivação após reconstrução.
| Decisão |
|---|
O manuseio operacional de chaves para LUKS e criptografia de disco completo é sensível à segurança; siga as orientações do fornecedor e da distribuição e o modelo de ameaça para o seu ambiente.
Um padrão concreto é uma unidade ou volume criptografado usando curvas Brainpool onde a sua pilha as exija (por exemplo, ECDH/ECDSA em torno de um segredo mestre), combinado com o Compartilhamento de Segredo de Shamir sobre o material de chave que desbloqueia essa criptografia (a mesma camada de segredo pequeno acima: SSS protege a chave, não o texto cifrado de vários gigabytes). Se e quando o firmware e o software do anfitrião que implementam esse fluxo de trabalho forem auditados de forma independente, essa combinação pode ser valiosa para organizações que precisam atender simultaneamente a políticas de quórum e perfis de criptografia nacional.
Por que as curvas Brainpool (ex.: BrainpoolP256r1, BrainpoolP384r1) são frequentemente discutidas nesse contexto:
Cenários onde a combinação de SSS com criptografia da classe Brainpool atende a necessidades institucionais (ilustrativo; não é aconselhamento jurídico ou de conformidade):
Se a assinatura OpenPGP estilo Governikus ou a atestação de eID nacional suportada por chip de nível comparável não estiver disponível ou não for prática para a sua jurisdição ou fluxo de trabalho, a secção Rede de Confiança e Festas de Assinatura de Chaves descreve uma abordagem alternativa do lado do anfitrião baseada em verificação presencial e assinaturas de terceiros em certificados.
A autenticação de chave OpenPGP do Governikus é um serviço online executado em nome do BSI (Gabinete Federal de Segurança da Informação da Alemanha). Após o submissor se autenticar com um cartão de identificação com capacidade de eID alemão, um cartão eID da UE para cidadãos da UE, ou uma autorização de residência eletrónica, o serviço verifica se o nome legal autenticado corresponde ao ID de utilizador OpenPGP na chave pública enviada. Se corresponder, o Governikus assina essa chave pública com a chave de assinatura do serviço, para que terceiros possam verificar a atestação.
Um fluxo de trabalho prático com este firmware: gere uma chave assimétrica Brainpool no token (geração de cartão OpenPGP como de costume), exporte a chave pública ou certificado para o anfitrião, complete o fluxo de submissão do Governikus incluindo autenticação eID (tipicamente AusweisApp e leitura NFC do cartão) e use a chave pública assinada devolvida pelo serviço (por exemplo, a partir de distribuição por e-mail). A chave privada permanece no Galdralag durante todo o processo.
Nenhum caminho substitui o outro. O passo eID e Governikus liga a chave pública à identidade verificada contra o chip no momento da submissão; eles não fornecem sigilo perfeito (forward secrecy), Shamir K-de-N para material de chave de longo prazo, ou perfis de cifra para dados em massa — esses são recursos específicos do firmware descritos noutro local neste README. O chip eID e o processo de emissão circundante também não implementam, por si só, o comportamento de ECDH efémero e de cascata do token. Por outro lado, uma chave OpenPGP Brainpool gerada no dispositivo alinha-se com o contexto de implantação do BSI/UE já discutido para uso institucional do Brainpool, mas sem um passo de atestação externa, os correspondentes devem confiar noutros meios para ligar uma impressão digital a uma pessoa jurídica.
| Camada | Função |
|---|---|
| Chave pública OpenPGP (ex.: Brainpool no Galdralag) | Estrutura criptográfica e controlo da chave privada no token; as escolhas de curva seguem as expectativas da classe BSI TR-03111 (veja as e a discussão sobre TR-03111 em ) |
Limitação: A verificação é baseada no nome. Se duas pessoas partilham o mesmo nome legal nos campos que o serviço compara, a atestação não as distingue; confirma a ligação de identidade a esse nome no momento da atestação, não a unicidade global. As preocupações habituais do OpenPGP (vinculação de e-mail, renovação de chave, revogação) permanecem em vigor.
Alinhamento de políticas: o mesmo BSI que define orientações técnicas relacionadas com Brainpool (BSI TR-03111; vetores de conformidade em crates/vault/tests/bsi_vectors/) também suporta o processo de assinatura eID do Governikus, o que muitas vezes é importante em ambientes alemães e da UE onde o Brainpool já é exigido ou preferido — veja Shamir mais Brainpool: exemplo e adequação institucional.
Âmbito mais amplo (nota de pesquisa, não um levantamento concluído): O mesmo padrão — ligar uma chave pública OpenPGP a uma identidade verificada por chip — é aplicável em princípio sempre que exista eID nacional; quais fornecedores oferecem um passo de assinatura semelhante ao do Governikus, e sob que regras, é uma questão separada que vale a pena investigar à medida que as implementações se expandem. Outros estados membros da UE executam ecossistemas eID baseados em cartão no âmbito do eIDAS que podem suportar âncoras de confiança comparáveis ou mais fortes do que o caminho alemão por si só; este README não os catalogou.
Tanto a Estónia como a Bélgica adotaram NIST P-384 no chip em vez de Brainpool, enquanto o perfil do BSI do setor público alemão se centra no Brainpool (veja acima). O Galdralag já suporta Brainpool, NIST P-256/P-384 e RSA para uso compatível com OpenPGP (Assimétrica / acordo de chave), pelo que o mesmo padrão de âncora de confiança não depende apenas de corresponder à preferência de curva da Alemanha.
Fora da UE/EEE, o padrão de âncora de confiança baseado em cartão é mais difícil de aplicar: os EUA têm um cartão com chip (PIV), mas está restrito a pessoal federal e situa-se no ecossistema X.509/FPKI, não integrado com OpenPGP; o Canadá não possui um cartão de assinatura nacional no chip no sentido usado acima. Isso limita o padrão principalmente a jurisdições com credenciais governamentais de chip emitidas universalmente — a área eIDAS da UE é onde o modelo é atualmente mais forte.
Quando e se o hardware atingir um estado pronto para o consumidor, as pessoas que desejam que o Compartilhamento de Segredo de Shamir e a troca de chaves efémera autenticada se tornem parte do comportamento interoperável OpenPGP / GnuPG (em vez de apenas funcionalidades específicas do firmware) precisariam de impulsionar mudanças nos padrões e implementação noutro local. Este repositório não fala pelo IETF ou pelo GnuPG; os locais abaixo são onde tais alterações são normalmente prosseguidas.
CESS — Cryptologically Enchanted Shamir's Secret — é um padrão criptográfico aberto para compartilhamento de segredo por limiar (threshold secret sharing) juntamente com criptografia autenticada agnóstica a cifras, embalagem de partes baseada em palavra-passe e opcional troca de chaves híbrida pós-quântica. O repositório CESS contém a especificação normativa, o registo de algoritmos, vetores de teste e o executor de conformidade.
Este firmware está em conformidade com o CESS para as construções aqui implementadas: as regras interoperáveis de parte e envelope da especificação coexistem com os mesmos temas de Shamir, Brainpool e perfil de cifra descritos noutro local deste README. O texto normativo é separado deste repositório; postura de conformidade (o que corresponde à especificação, o que difere enquanto retém algoritmos como AES e SHA-256 nos perfis, e roteiro para interoperabilidade mais forte): docs/CESS_CONFORMANCE.md.
Se os mantenedores deste repositório GitHub não responderem a issues, pull requests ou e-mail, ainda pode avançar com novas cifras, comportamento OpenPGP e trabalho relacionado com padrões no ecossistema mais amplo. Sequoia PGP é uma pilha OpenPGP independente, baseada em Rust (segurança de memória, design centrado em bibliotecas, participação ativa no IETF/ecossistema) onde grande parte do desenvolvimento público acontece. Não é este projeto; está documentado aqui como um caminho alternativo prático quando o upstream aqui estiver silencioso.
A página Contribute descreve o licenciamento (LGPL 2.0 ou posterior para a maioria dos projetos), o Certificado de Origem do Desenvolvedor e que funcionalidades comerciais maiores podem exigir acordo prévio e acordos de manutenção a longo prazo — leia essa página antes de investir esforço significativo.
Também vale a pena ficar de olho em https://autocrypt2.org/#/
Este código base e aplicações relevantes não serão compilados para macOS ou Windows. As ferramentas do anfitrião (galdra, galdrad, galdra-gtk) e ferramentas auxiliares têm como alvo Linux. Esta é uma decisão deliberada baseada no modelo de ameaça do projeto e nos requisitos de auditabilidade declarados ao longo deste documento.
_NSAKEY descoberta no Windows NT em 1999 causou controvérsia significativa. A Microsoft afirmou que era uma chave de backup; isto nunca foi totalmente provado de qualquer forma.Suspeito, mas não comprovado:
main, restricted, universe e multiverse são assinados pela chave GPG da Canonical.security.ubuntu.com, que também é assinado.Os gestores de pacotes são geralmente seguros, mas instalações de terceiros em .deb / .rpm / AppImage podem ser inseguras. Prefira pacotes assinados de repositórios confiáveis e verifique assinaturas antes de instalar qualquer coisa obtida fora deles.
Use uma cadeia de ferramentas Rust estável conforme fixada em rust-toolchain.toml. O firmware usa o alvo riscv32imac-unknown-none-elf; as ferramentas do anfitrião usam o tripleto do anfitrião.
test-hal vazar para builds de produção): ```bash
cargo run -p xtask -- check-fw
Código objeto e arquivos ficam em target/riscv32imac-unknown-none-elf/release/. Uma imagem de sistema Xous inicializável completa para uma placa específica é produzida pelo fluxo de integração mais amplo do Baochip / Xous quando você segue a compilação desse produto; o xtask aqui executa cargo build para as crates da biblioteca de firmware listadas em xtask (não um único arquivo pronto para gravação por si só).
galdralag-service) — precisa da toolchain riscv32imac-unknown-xous-elf do Xous (não a triple riscv32imac-unknown-none-elf de firmware nua acima). A partir da raiz do repositório: cargo run -p xtask -- build-and-register release. Isso reconstrói o ELF, verifica-o no disco, imprime o cratespec baosec e opcionalmente executa cargo xtask baosec quando fornecido --xous-core /caminho/para/xous-core. Detalhes: services/galdralag/README.md.Este repositório não inclui ainda um comando único de gravação. A programação do Baochip-1x (JTAG, boot ROM/USB ou ferramentas do fabricante) segue a documentação da placa e do silício. Comece por Supermagnum/Baochip-1x-firmware; o hardware da placa de avaliação está em baochip/dabao — na placa Dabao, o SW2 alterna o modo bootloader (veja esse esquema).
Enviar UF2 sem o botão físico de boot: Após copiar loader.uf2, xous.uf2 e apps.uf2 para o volume BAOCHIP, você pode pressionar o botão boot físico ou digitar boot no console serial USB boot1 (1 000 000 baud, ex.: screen /dev/ttyACM0 1000000). Isso evita depender do botão boot apenas nesta etapa. O console desconecta quando você digita boot; isso é esperado (o sistema reinicia para o próximo estágio). No Linux, dmesg --follow ajuda a confirmar a reenumeração USB. Isso é diferente de PROG (segure enquanto conecta USB para entrar no bootloader de armazenamento em massa BAOCHIP). Veja baochip/dabao#2 (fechado).
Fluxo Xous / Baochip: As imagens são assinadas com Ed25519 e verificadas pelo boot0 antes da execução; veja Firmware assinado (Ed25519, boot0). Para dabao, layout UF2, segurar PROG ao conectar USB para entrar no modo de armazenamento em massa e etapas de atualização do boot1, veja Getting Started with Baochip Targets.
galdra, galdrad, galdra-gtk)As crates do host ficam na raiz do workspace: galdra/, galdrad/, galdra-gtk/.
Ubuntu / Debian (instalar antes de cargo build / cargo install):```bash
sudo apt update
sudo apt install build-essential pkg-config libpcsclite-dev pcscd libssl-dev
galdra-gtk:sudo apt install libgtk-4-dev
`libpcsclite-dev` satisfaz o caminho de ligação **padrão** do **`galdra`** **PC/SC**; **`pcscd`** é o daemon que serve leitores de smart cards em tempo de execução. **`libssl-dev`** é necessário para que **openssl-sys** possa fazer a ligação (as consultas ao keyserver do **sequoia-net** e o TLS do **ldap3** usam **native-tls** atualmente). Omita **`libgtk-4-dev`** se nunca compilar **`galdra-gtk`**.
**GTK 4 (apenas `galdra-gtk`):** `pkg-config` deve resolver **gtk4** (crate do workspace **`gtk`** 0.9.x, pacote **`gtk4`**). No Fedora use **`gtk4-devel`**; no Arch **`gtk4`**.
Compile os binários de release a partir da raiz do repositório:```bash
cargo build --release -p galdra -p galdrad -p galdra-gtk
Executáveis: target/release/galdra, target/release/galdrad, target/release/galdra-gtk.
Instalar em ~/.cargo/bin (ajuste --path se você não estiver na raiz do repositório):```bash
cargo install --locked --path galdra
cargo install --locked --path galdrad
cargo install --locked --path galdra-gtk
Você pode, em vez disso, copiar esses três binários para qualquer diretório no seu `PATH`.
### Executar `galdrad` e a GUI de desktop (`galdra-gtk`)
**`galdra-gtk`** é o binário de desktop GTK4 (pacote Cargo **`galdra-gtk`**; não há **`galdra-gui`**). É um front-end para a API REST do **`galdrad`** — execute **`galdrad`** primeiro.
**Daemon** — **`galdrad`** escuta em **`127.0.0.1:8742`** por padrão (`--listen` substitui); veja [`galdrad/src/main.rs`](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/galdrad/src/main.rs).```bash
galdrad
Verificação rápida: curl -s http://127.0.0.1:8742/health (docs interativos da API: http://127.0.0.1:8742/swagger-ui/.)
GUI de Desktop — galdra-gtk usa http://127.0.0.1:8742 por padrão (--base-url ou GALDRAD_URL); veja galdra-gtk/src/main.rs.```bash
galdra-gtk
galdra-gtk --base-url http://127.0.0.1:8742
GALDRAD_URL=http://127.0.0.1:8742 galdra-gtk
From a fresh **`cargo build --release`**, without installing: **`./target/release/galdrad`** then **`./target/release/galdra-gtk`** from the repo root.
**Host vs token:** **`galdra-gtk`** espelha o que **`galdrad`** expõe sobre HTTP; os fluxos de token **unlock**, **provision** e outros CCID permanecem no CLI do **`galdra`** (consulte **`galdra device`** em **[docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md)** e Nível **2c**).
**Diretório de contactos (`galdra contact`, `galdrad` `/contacts`):** criar um contacto **requer um e-mail** (CLI: `--email`; HTTP: campo JSON `email`). Os campos opcionais incluem **nome de exibição** (`--name` / `name`), **organização** (**`--org`** / `org`), **cargo**, **distintivo** (**`--badge`** / `badge`), **nota**, **callsign**, **Fluxer**, **Discord** e **IRC** ids, **número de telefone** (`--phone-number` / `phone_number`), além de **dicas postais** (`street`, `country`, `postal_code`, `region`), **`dmr_id`** de rádio-amador e **`radio_affiliation`**. Estes valores são armazenados apenas nos metadados SQLite locais (não são **verificados** contra serviços externos). A **pesquisa** de um contacto (por exemplo `galdra contact show`, caminhos `PATCH`/`DELETE`, `galdrad` **`GET /contacts/{id}`**, IDs de membros de grupo, ou **`POST /decrypt`** `recipient`) aceita o **UUID** da linha, **callsign**, **e-mail**, uma **impressão digital OpenPGP v4 hexadecimal de 40 caracteres** (espaços ignorados), esses IDs sociais, ou um **ID de subscritor DMR** em **1..16777215** quando dado como token decimal. **`galdra keyserver push`** pode espelhar muitos dos mesmos rótulos para um registo estilo Fulla (**`organisation`**, **`role`**, **`note`**, **`badge_number`**, **`phone_number`**, campos de rádio/sociais/postais e nomes — veja **`galdra keyserver push --help`**). Os comandos e limites de campo estão resumidos em **[docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md)** nas secções **Contacts** e **Identity model**.
### Desinstalar ferramentas do host
Se usou `cargo install --path` como acima:```bash
cargo uninstall galdra
cargo uninstall galdrad
cargo uninstall galdra-gtk
Se você copiou binários manualmente, remova os arquivos que adicionou. O firmware não é "instalado" no host; apagar ou regravar o dispositivo é coberto pela documentação do seu hardware.
Os itens abaixo são capacidades do firmware Galdralag, não requisitos da aplicação de cartão OpenPGP ou do GnuPG.
Modelo de segurança pronto para três fatores — Posse do token USB e conhecimento do PIN são aplicados no firmware atualmente; um terceiro fator biométrico opcional não está implementado neste repositório (placeholder: docs/BIOMETRIC_API.md). Consulte docs/THREE_FACTOR_AUTH.md para escopo e limites.
ECDH efêmero autenticado no dispositivo — verdadeiro sigilo de encaminhamento criptográfico. Cada sessão gera um novo par de chaves efêmeras no TRNG de hardware do token. A chave de longo prazo assina a oferta efêmera mas nunca participa do acordo de chaves. Sessões passadas não podem ser descriptografadas mesmo com uma chave de longo prazo totalmente comprometida. Pelo conhecimento dos autores do projeto, nenhum token de segurança de hardware comercial fornece isso como um recurso de primeira classe.
Compartilhamento de segredo Shamir K-de-N no dispositivo — a chave de longo prazo pode ser dividida em N partes exigindo K para reconstruir, sem que um único detentor consiga recuperar a chave sozinho. Pelo conhecimento dos autores do projeto, nenhum token comercial fornece isso como um recurso de primeira classe.
Sistema de perfil agnóstico a cifras — cifras simétricas, curvas ECDHE e configuração Shamir são combinadas em perfis nomeados e auditáveis. Para dados em massa sob um perfil, o texto simples é criptografado de dentro para fora: você pode empilhar até quatro diferentes AEADs simétricos uns sobre os outros — então você pode usar três cifras independentes em um perfil (por exemplo ChaCha20-Poly1305, depois Serpent-256, depois Twofish-256), ou uma quarta camada distinta onde a política permitir — com nenhuma cifra repetida no mesmo perfil e material de chave e nonce derivados por HKDF independente por camada. Nomes embutidos como standard, conservative e conservative-shamir vêm com camadas; pilhas mais profundas são para perfis avançados ou personalizados. Regras completas e layout de transmissão: . Cada seleção de perfil é registrada na trilha de auditoria.
Todos os primitivos vêm de dependências de workspace auditadas independentemente. Nada é implementado na árvore.
pin-policy ser chamado. Entradas curtas não incrementam o contador.HMAC-SHA256(HostChallengeKey, nonce || passphrase).Definir ou ajustar o limite de tentativas: O limite do contador é escrito quando o token é provisionado pela primeira vez; não é uma configuração de tempo de execução do gpg. Use a ferramenta host galdra após compilá-la:```bash
galdra device provision --pin-attempts 5
| Bandeira | Faixa | Padrão | Significado |
|------|--------|---------|---------|
| `--pin-attempts` | 3–10 | **3** | Tentativas de PIN inválidas permitidas antes do bloqueio / zeroização |
| `--min-pin-length` | 5–32 | **5** | Comprimento mínimo do PIN do usuário (alfanumérico) armazenado na política |
Omite ambas as bandeiras para manter os padrões (3 tentativas, mínimo de 5 caracteres). Exemplo com ambas: `galdra device provision --pin-attempts 7 --min-pin-length 8`.
A política é **armazenada no token** (política do cofre). A ferramenta host não pode aumentar ou diminuir o limite **após** o provisionamento sem passar pelo próprio fluxo de gerenciamento autenticado do dispositivo; trate o provisionamento como o momento de escolher **3–10** para o seu modelo de ameaça. A justificativa (padrões vs limites superiores) está explicada em [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/GALDRA-TOOL.md) na seção de política de PIN.
---
## Status pós-quântico
### Implementado — crate não auditada (com feature gate)
XMSS (RFC 8391, NIST SP 800-208) e LMS/HSS (RFC 8554, NIST SP 800-208)
são implementados atrás de `--features pq-signatures`. As crates Rust subjacentes
não foram auditadas independentemente. Veja
[docs/PQ_SIGNATURES.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/PQ_SIGNATURES.md) e
[docs/STATEFUL_SIG_STATE.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/STATEFUL_SIG_STATE.md).
### Pendente de auditoria independente — ainda não implementado
Estes algoritmos são padronizados pelo NIST. A implementação está bloqueada até
que uma crate Rust `no_std` auditada independentemente esteja disponível.
| Algoritmo | Padrão | Aguardando |
|-----------|--------|---------|
| ML-KEM | FIPS 203 | Crate Rust `no_std` auditada |
| ML-DSA | FIPS 204 | Crate Rust `no_std` auditada |
| SLH-DSA | FIPS 205 | Crate Rust `no_std` auditada |
| FN-DSA (FALCON) | FIPS 206 draft | Finalização do padrão + crate auditada |
| HQC | Draft ~2027 | Finalização do padrão + crate auditada |
**Nota sobre libcrux:** Um artigo académico de 2026 identificou bugs ao nível
da especificação nas implementações de ML-KEM e ML-DSA formalmente verificadas
do libcrux, incluindo provas tornadas insustentáveis. Verifique o changelog do
libcrux antes de avaliá-lo.
### Não será implementado
**BIKE** foi eliminado da padronização do NIST em março de 2025 em favor do
HQC. A criptografia **NTRU** foi eliminada em julho de 2022. Nenhum dos dois
tem caminho para um padrão NIST.
---
## Zeroização — ressalva de hardware
A implementação de zeroização é **correta em software, mas não verificada em
hardware**. Foi testada apenas com simulação `test-hal`. A verificação física
no silício Baochip-1x (inspeção de memória JTAG, resiliência a ciclos de
energia, confirmação por canais laterais) ainda não foi realizada. Veja
[docs/HARDWARE_VERIFICATION.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/HARDWARE_VERIFICATION.md). A **ordem de
regiões** e **âncoras de layout** pretendidas para os subsistemas do cofre
estão resumidas em [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/RRAM_LAYOUT.md); a ordem de
**apagamento físico** permanece como trabalho de integração da plataforma e
**boot0**.
---
## Resultados dos testes
Escrita autoritativa: **[`docs/TEST_RESULTS.md#run-metadata`](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/TEST_RESULTS.md#run-metadata)**
(commit, escopo e como as seções estão organizadas). Essa página inclui a
tabela de **resumo do pipeline**, totais de testes unitários, cobertura de
vetores (Wycheproof, RFC, BSI TR-03111 ECDH + ECDSA, NIST CAVP, BLAKE3
hash/keyed-hash/derive-key), tabela de temporização **dudect**, verificações
do ciclo de vida das chaves e
**[Seção 6 — cargo-fuzz](https://github.com/supermagnum/galdralag-firmware/blob/HEAD/docs/TEST_RESULTS.md#6-cargo-fuzz-libfuzzer)**
(matrizes, **`chacha_roundtrip`**, execução longa registrada de
**`openpgp_dispatch`**). **Você** decide se esses resultados são suficientes
para tentar compilar ou executar este projeto; uma **máquina virtual** permanece
opcional, mas **reduz** o risco para o host.```
cargo run -p xtask -- test-all
Crates orientados a firmware em crates/ e binários host na raiz do repositório (veja a raiz Cargo.toml [workspace] para a lista autoritativa de membros):
Não nesta tabela do workspace como crates separados: baochip-openpgp e services/galdralag são construídos via --manifest-path (veja a raiz Cargo.toml exclude e services/galdralag/README.md). O armazenamento de bloco em massa/falso opcional (psram-store em documentos de design) não é ainda um membro do workspace; veja docs/Psram.md, docs/dev-ref.md, e docs/SDMMC_STORAGE_INTEGRATION.md.
Primitivas não são implementadas na árvore. Todo o trabalho criptográfico usa dependências auditadas do workspace do projeto RustCrypto (exceto vsss-rs e a família dalek, que passaram por revisão independente):```
aes-gcm chacha20poly1305 ed25519-dalek x25519-dalek
hkdf pbkdf2 hmac sha2 sha3 blake2 blake3
vsss-rs zeroize subtle p256 p384
Usar crates auditados significa que este projeto herda seu histórico de auditoria em vez de introduzir código criptográfico não revisado.
---
## Início rápido
Os pré-requisitos de compilação do firmware e os caminhos de instalação estão em [Compilar, instalar e desinstalar](#build-install-and-uninstall) acima.
**GUI de área de trabalho do host (`galdra-gtk`):** após [compilar/instalar](#compile-and-install-host-tools-galdra-galdrad-galdra-gtk) **`galdrad`** e **`galdra-gtk`**, inicie **`galdrad`** e depois **`galdra-gtk`** ([passo a passo](#run-galdrad-and-the-desktop-gui-galdra-gtk)).```bash
rustup target add riscv32imac-unknown-none-elf
cargo test --workspace --exclude xtask
cargo run -p xtask -- check-fw
cargo run -p xtask -- build-fw
cargo run -p xtask -- test-host
cargo run -p xtask -- test-all
cargo run -p xtask -- test-biometric
cargo run -p xtask -- timing-test biometric
cargo run -p xtask -- fuzz biometric_dispatch 60
cargo run -p xtask -- timing-test
# Xous CCID daemon (separate triple; see [Build, install, and uninstall](#build-install-and-uninstall) step 4):
# cargo run -p xtask -- build-and-register release
Fuzzing (libFuzzer): instale cargo-fuzz, use nightly, então, ex.: cargo run -p xtask -- fuzz chacha_roundtrip 60 ou cargo run -p xtask -- fuzz openpgp_dispatch 60 (caminho OpenPGP APDU) ou cargo run -p xtask -- fuzz biometric_dispatch 60 (caminho CBOR biométrico). Nomes de alvos, aliases xtask e sementes de corpus recomendadas por alvo estão em fuzz/README.md.
Ative a feature test-hal do galdr-core apenas em testes ou ferramentas de host.
Nunca ative em imagens de firmware de produção — imposto por check-fw.
---
[Read more](https://github.com/supermagnum/galdralag-firmware)
| Campo | Propósito | Anfitrião (galdra SQLite) | Contact store no chip | Formato / limite |
|---|
| ID de contacto | Chave primária estável do anfitrião | Sim | Não | Texto (id in SQLite) |
| Nome de exibição | Rótulo legível por humanos | Sim | Sim | String UTF-8; 240 bytes máx por campo heap no chip |
| Endereço de correio eletrónico principal | Sim | Sim | String UTF-8; pesquisa no chip por scan de e-mail | |
| Callsign | Indicativo de rádio amador | Sim | Sim | 12 bytes, preenchido com NUL; pesquisa no chip |
| ID de subscritor DMR | ID de rádio DMR | Sim | Sim | 32-bit unsigned (0 = ausente); pesquisa no chip |
| Número de badge | ID de funcionário ou badge | Sim | Sim | String UTF-8 |
| Organização | Agência ou empregador | Sim | Sim | String UTF-8 |
| Departamento | Equipa ou unidade | Sim | Sim | String UTF-8 |
| Função | Rótulo de trabalho ou função | Sim | Sim | String UTF-8 |
| Nota | Comentário de forma livre | Sim | Sim | String UTF-8 |
| Afiliação de rádio | Rótulo de clube, rede ou aliança | Sim | Sim | String UTF-8 |
| Rua | Linha de endereço | Sim | Sim | String UTF-8 |
| País | Nome ou código do país | Sim | Sim | String UTF-8 |
| Código postal | Código ZIP ou postal | Sim | Sim | String UTF-8 |
| Região | Estado, condado ou região | Sim | Sim | String UTF-8 |
| ID Fluxer | Handle ou id Fluxer | Sim | Sim | String UTF-8 |
| ID Discord | ID de utilizador Discord | Sim | Sim | String UTF-8 |
| ID IRC | nick IRC ou semelhante | Sim | Sim | String UTF-8 |
| Número de telefone | Número de contacto voz ou SMS | Sim | Não | String UTF-8; 32 caracteres máx no anfitrião; declarado pelo submissor, não verificado |
| Impressão digital | Âncora de chave (pesquisa, sincronização) | Sim (pgp_fingerprint) | Sim | 32 bytes; estilo OpenPGP v4 no fio; não o mesmo que uma impressão digital de dispositivo G: |
| Chave pública | Material de encriptação/verificação | Sim (pgp_pubkey) | Sim (região de chave) | Algoritmo: Ed25519, X25519, Brainpool P-256/P-384/P-512, NIST P-256/P-384, RSA-2048/3072/4096; até 768 bytes blob no chip |
| Chave protegida por PIN | Chave requer desbloqueio por PIN | Anfitrião armazena chaves OpenPGP separadamente | Sim | Digest verificador PIN + metadados de wrap AES-GCM no chip |
| Última obtenção | Quando o material de chave foi atualizado | Sim (fetched_at) | Sim (last_fetched) | UTC no anfitrião; timestamp 32-bit no chip |
| Expira em | Tempo de expiração da chave | Sim | Não | datetime UTC apenas no SQLite |
| Origem da chave | Como o registo do anfitrião foi criado | Sim (source) | Não | e.g. manual, keyserver, WKD, LDAP, ficheiro, peer |
| Proveniência do campo | Rótulo de confiança por campo de metadados | Não | Sim (source_map) | Dois bits por campo: SelfAttested, HostVerified, RegistrySync, OobVerified |
| Flags de registo | Ativo, desatualizado, própria identidade, revogado | Parcialmente (lógica do anfitrião) | Sim | e.g. STALE, SELF_KEY no chip |
fuzz/README.mddocs/TEST_RESULTS.md para o que está no âmbito.| Campo de metadados | OpenPGP / GnuPG | Chave Galdra (host + loja de contatos) |
|---|
| ID de contato / registro | Não (use ID ou impressão digital da chave) | Sim (id SQLite no host; não no chip) |
| Nome de exibição | Apenas dentro do texto do User ID (Nome <email>) | Sim (campo UTF-8 separado) |
| Apenas dentro do texto do User ID | Sim (campo separado; consulta por e-mail no chip) | |
| Endereço | Nenhum campo padrão | Sim |
| País | Nenhum campo padrão | Sim |
| CEP | Nenhum campo padrão | Sim |
| Região / estado | Nenhum campo padrão | Sim |
| Organização | Nenhum campo padrão | Sim |
| Departamento | Nenhum campo padrão | Sim |
| Cargo / função | Nenhum campo padrão | Sim |
| ID de crachá / funcionário | Nenhum campo padrão | Sim |
| Indicativo | Nenhum campo padrão | Sim (12 bytes, preenchido com NUL no chip) |
| ID de assinante DMR | Nenhum campo padrão | Sim (32 bits; consulta no chip) |
| Afiliação de rádio | Nenhum campo padrão | Sim |
| Fluxer ID | Nenhum campo padrão | Sim |
| Discord ID | Nenhum campo padrão | Sim |
| IRC id | Nenhum campo padrão | Sim |
| Número de telefone | Nenhum campo padrão | Sim (apenas SQLite do host) |
| Nota livre | Nenhum campo padrão | Sim |
| Impressão digital OpenPGP v4 | Sim (40 caracteres hex) | Opcional na linha do host ao vincular um certificado (pgp_fingerprint); 32 bytes no chip para chaves Galdra |
Impressão digital do dispositivo G: | Não | Sim (BLAKE3-160 sobre chave pública SIG; ferramenta do host; não o valor OpenPGP v4) |
| ID de chave OpenPGP | Sim (forma curta / longa) | Não |
| Confiança / proveniência | Assinaturas WoT em User IDs | Rótulos por campo: SelfAttested, HostVerified, RegistrySync, OobVerified (no chip) |
| Expiração da chave | Sim (certificado / subchave) | Apenas host (expires_at no SQLite) |
| Último momento de busca da chave | Dependente das ferramentas do host | Sim (fetched_at / last_fetched) |
| Chave privada no token | Slots de cartão SIG, DEC, AUT | Região de chave Galdra separada (não pacotes User ID) |
| PIN para usar chave privada | PW1 / PW3 (cartão OpenPGP) | PIN opcional por registro de contato Galdra |
| Objeto de cartão OpenPGP (não na tabela acima) | Host (GnuPG) | No token |
|---|
| Chave primária + subchaves SIG / DEC / AUT | Pública no chaveiro | Privada em slots selados |
| Assinaturas de certificação (WoT) | Sim | Não |
| Certificado de revogação | Sim | Não |
| Atributos de algoritmo (DO 0xC1 / 0xC2 / 0xC3) | gpg --card-edit | Sim |
| PW1 / PW3 | Nunca armazenado | Verificador no chip (mín 5 caracteres, 3 tentativas padrão) |
| DOs do titular do cartão (login, idioma, URL, …) | Cacheado pelo GnuPG | Opcional (254 bytes máx por DO) |
galdragaldra-core-host| Escopo | Padrão / documento típico | Exposto como cartão OpenPGP padrão + GnuPG? |
|---|
| Aplicação de cartão OpenPGP — APDUs, PINs, slots SIG/DEC/AUT, gerar/assinar/decifrar no cartão | Especificação do cartão OpenPGP (veja docs/OPENPGP_CARD.md) | Sim — mesma pilha host que outros smart cards OpenPGP (gpg, scdaemon, CCID) |
| USB CCID — comunicar com o dispositivo como um leitor de smart card | Classe de dispositivo USB CCID | Sim — drivers de classe |
| Formato de mensagem OpenPGP — arquivos criptografados, e-mail, pacotes de chave | RFC 4880 (e atualizações) | Sim no host — GnuPG usa isto; o cartão não analisa e-mail |
| Shamir K-de-N — dividir/recuperar material de chave de longo prazo no cofre | Não na especificação do cartão OpenPGP; não no GnuPG | Não — apenas firmware e ferramentas de provisionamento; não é uma operação gpg --card-edit (veja Shamir e criptografia de disco completo) |
| ECDH efêmero autenticado — protocolo de sessão com sigilo perfeito no token | Não na especificação do cartão OpenPGP | Não — específico do token; não é um comando do cartão GnuPG |
| Sistema de perfil de cifra — cascatas simétricas nomeadas (empilhar cifras independentes umas sobre as outras; até quatro camadas, três é uma profundidade suportada) e política relacionada | Não na especificação do cartão OpenPGP | Não — firmware / ferramentas de token host |
| Personas microSD de isca / armazenamento em massa — comportamento USB para host desinformado | Não na especificação do cartão OpenPGP | Não — caminhos de código de personalidade USB separados |
| WebAuthn / FIDO2 | CTAP / WebAuthn | Não implementado — padrão diferente do cartão OpenPGP |
| Camada | Função |
|---|
| Disco | Criptografado com uma chave mestre (ex: AES-256 via LUKS, VeraCrypt, ou uma camada de bloco bruta) |
| Chave mestre | Dividida com SSS em N partes, limiar K-de-N |
| Partes | Mantidas por pessoas, dispositivos ou armazenamento off-line; K partes juntas reconstroem a chave mestre |
| Desbloqueio | Reconstruir chave, depois passá-la para cryptsetup, veracrypt, ou sua pilha |
| Opções típicas |
|---|
| Limiar (threshold) | 2-de-3 (pequena equipa, alguma redundância); 3-de-5 (comum em organizações) |
| Armazenamento das partes | Tokens de hardware, máquinas separadas, papel, locais geograficamente separados |
| Proteção das partes | Criptografar cada parte para um destinatário específico (ex.: com a chave OpenPGP desse destinatário) antes da distribuição |
| Onde reconstruir | Máquina isolada (air-gapped), política HSM ou ambiente controlado — não em servidores partilhados não confiáveis |
| Cenário | Por que SSS mais curvas fortes e alinhadas com políticas são importantes |
|---|
| Saída ou falecimento de funcionário | A recuperação permanece possível sem o segredo exclusivo dessa pessoa |
| Acesso legal sob processo legal | Um quórum pode ser exigido — nenhuma parte detém sozinha o segredo completo de desbloqueio |
| Custódia corporativa de chaves | Divisão auditável; nenhum administrador individual tem acesso completo |
| Apreensão de hardware | A mídia pode ser capturada sem capturar K de N partes |
| Alinhamento regulatório (UE / BSI) | Brainpool atende a muitos requisitos de criptografia governamental alemã e da UE |
| Assinatura Governikus | Confirma que o nome no certificado correspondeu à identidade autenticada por chip quando o utilizador completou o fluxo |
| Jurisdição | Estado abordado neste documento |
|---|
| Alemanha | Fluxo Governikus/BSI descrito acima |
| Estónia | eID baseado em chip. Migrou de RSA para NIST P-384 (secp384r1) ECDSA em 2017–2018 após a vulnerabilidade ROCA forçar o abandono total do RSA (o chip não conseguia gerar chaves RSA seguras e não tinha caminho para tamanhos de chave maiores). A chave privada está vinculada ao hardware e não pode ser lida do cartão. Nenhum serviço de assinatura OpenPGP estilo Governikus encontrado. |
| Bélgica | eID baseado em chip. Cartões mais antigos usavam RSA 1024 bits; cartões mais novos (applet 1.8 em diante) usam NIST P-384 ECDSA. Ecossistema ativo de middleware de código aberto (eid-mw, OpenSC). Nenhum serviço de assinatura OpenPGP estilo Governikus encontrado. |
| Noruega | O chip do cartão de identificação nacional (emitido desde 2020) é compatível com ICAO 9303 e implementa apenas um chip de documento de viagem; não possui função de assinatura eID. A eID de assinatura é separada: fornecedores privados acreditados (Buypass, Commfides) sob o SEID, historicamente RSA 2048 bits, a migrar para RSA 3072 bits com ECC introduzido no SEID 2.0. Nenhum serviço de assinatura OpenPGP estilo Governikus encontrado. O chip de viagem e a eID de assinatura são distintos — relevante se alguém tentar usar apenas o chip do cartão diretamente. |
| Áustria | Parcialmente investigado. O eID usa ECC (confirmado); a curva específica não foi confirmada nas fontes disponíveis. Modelo Bürgerkarte com múltiplos tokens em vez de um único cartão; amplamente migrado para uma aplicação móvel. É necessária mais investigação sobre detalhes da curva e qualquer serviço de assinatura OpenPGP. |
| EUA | Cartão PIV (Personal Identity Verification, FIPS 201 / NIST SP 800-78): emitido apenas para funcionários e contratantes federais — não é um cartão civil universal. Algoritmos: NIST P-256 obrigatório para chaves de autenticação; P-256 ou P-384 para assinatura/gestão de chaves; RSA 2048/3072 também permitido; apenas curvas NIST, nenhuma Brainpool. A raiz de confiança é a Federal Common Policy CA (FCPCAG2), não incluída nas lojas de confiança comerciais padrão. Nenhum serviço de assinatura OpenPGP estilo Governikus encontrado; o FPKI é uma infraestrutura X.509 separada do OpenPGP. O facto de o PIV ser apenas federal significa que não é uma âncora de confiança civil como o eID alemão. |
| Canadá | Nenhum cartão de identificação nacional baseado em chip com chaves de assinatura no chip. A identidade digital está fragmentada em esquemas provinciais (por exemplo, BC Services Card), aplicações móveis (por exemplo, eID-Me) e um quadro federal de credenciais digitais em evolução. Nenhum cartão único comparável ao modelo alemão, estónio ou belga. Nenhuma infraestrutura de cartão equivalente encontrada — não é uma âncora de confiança viável neste sentido. |
| Outros países | Não investigado |
| Objetivo | Onde começar |
|---|
| Visão geral do projeto, notícias, comunidade | sequoia-pgp.org |
| Contribuir (issues, correções, funcionalidades, documentação); contactar antes de trabalho grande | Contribute, Contact |
Documentação para programadores — superfície da API para estender a implementação (sequoia-openpgp e crates relacionadas) | Docs — ex.: sequoia-openpgp no docs.rs |
| Código fonte e rastreadores | gitlab.com/sequoia-pgp (biblioteca principal e ferramentas); github.com/sequoia-pgp (espelhos / repositórios selecionados); Projects |
| Novos algoritmos no padrão OpenPGP | Ainda passam pelo grupo de trabalho IETF OpenPGP. O Sequoia e outras implementações implementam drafts e RFCs; proponha alterações ao protocolo lá e coordene com implementadores (incluindo Sequoia) para que o comportamento corresponda à especificação. |
BLAKE3 chaveado entre camadas em cascata (CESS) — Além da tag AEAD de cada camada e do envelope externo Modo A ChaCha20-Poly1305, o CESS define integridade no estilo BLAKE3 chaveado entre estágios internos da cascata. Para perfis mapeados por registro (suite_id via nomes embutidos), cipher-profile anexa um HMAC-BLAKE3 de 32 bytes sobre a saída AEAD de cada camada interna antes da próxima camada criptografar; as chaves são derivadas com HKDF-BLAKE3 usando cess::cess_blake3_integrity_gap_info (inner_info.rs). Camada única embutida pula tags extras; perfis personalizados (sem suite_id) mantêm a cascata legada sem MACs entre camadas. Consulte docs/CIPHER_PROFILES.md e docs/CESS_CONFORMANCE.md. Contagens de combinação sob as regras de cifra cipher-profile (cinco primitivas AEAD, nenhuma cifra repetida em um perfil, ordem importa); a coluna BLAKE3 é a contagem de espaço de design do CESS (liga/desliga independente por lacuna), não uma alternância por mensagem no host:
O valor 205 conta apenas pilhas de cifras (permutações de 1–4 escolhas distintas de AES-256-GCM, ChaCha20-Poly1305, Twofish-256, Serpent-256, Camellia-256). O valor 1245 é as mesmas pilhas multiplicadas por cada padrão independente de ativado/desativado para BLAKE3 opcional entre camadas (2^(k−1) padrões para k camadas). Este firmware aplica MACs entre camadas para todas as lacunas quando um perfil embutido suite_id tem ≥ 2 camadas (não uma alternância por lacuna). Nomes de perfil embutidos usam um subconjunto pequeno dos 205.
Volume isca microSD opcional — se um chip PSRAM estiver montado, um LUN de massa isca extra pode aparecer após o desbloqueio. Se nenhum microSD estiver montado, o dispositivo ainda é um token de segurança de hardware (cofre, política de PIN, OpenPGP/CCID e outras funções de token permanecem inalteradas); apenas esse volume opcional de massa está ausente. Para hosts desinformados, o dispositivo ainda apresenta a persona de armazenamento em massa isca no chip usual quando configurado. O conteúdo do microSD, quando presente, é intencionalmente não criptografado e sem destaque. O material de chave real reside na RRAM no chip por trás do cofre e da política de PIN.
Pilha totalmente aberta — RTL CERN-OHL-W-2.0, esquemáticos abertos, bootloader reproduzível, sistema operacional Rust/Xous, silício inspecionável por IRIS.
| Algoritmo | Padrão | Notas |
|---|
| BrainpoolP256r1 ECDH + ECDSA | RFC 5639, BSI TR-03111 | Padronizado pela BSI, sem envolvimento da NSA |
| BrainpoolP384r1 ECDH + ECDSA | RFC 5639, BSI TR-03111 | Segurança de ~192 bits |
| X25519 ECDH | RFC 7748 | |
| Ed25519 sign / verify | RFC 8032 | |
| RSA-2048 / 3072 / 4096 OAEP, PSS | RFC 8017 | Mínimo de 2048 bits exigido |
| P-256, P-384 | NIST | Através das dependências de workspace p256 / p384 |
| Algoritmo | Padrão | Notas |
|---|
| AES-256-GCM | FIPS 197, NIST SP 800-38D | AES por hardware no Baochip-1x |
| ChaCha20-Poly1305 | RFC 8439 | Sem envolvimento da NSA |
| Twofish-256 | Schneier et al. 1998 | Finalista do AES, sem envolvimento da NSA |
| Serpent-256 | Anderson / Biham / Knudsen 1998 | Finalista do AES, 32 rodadas, margem conservadora |
| Algoritmo | Padrão |
|---|
| HKDF (SHA-256 / SHA-512) | RFC 5869 |
| HMAC (SHA-256 / SHA-512) | RFC 2104 |
| PBKDF2 | RFC 8018 |
| SHA-2 (224 / 256 / 384 / 512) | FIPS 180-4 |
| SHA-3 family | FIPS 202 |
| BLAKE2b / BLAKE2s | RFC 7693 |
| BLAKE3 | BLAKE3 specification |
| Recurso | Notas |
|---|
| Compartilhamento de segredo Shamir K-de-N | vsss-rs — divisão e recuperação no dispositivo |
| ECDH efêmero autenticado | Protocolo de sessão com sigilo de encaminhamento — crate ephemeral-session |
| Sistema de perfil de cifra | Cascata simétrica: até quatro AEADs diferentes empilhados (ex.: três camadas independentes); chaves por camada — cipher-profile — docs/CIPHER_PROFILES.md |
| Propriedade | Implementação |
|---|
| Sigilo de encaminhamento | ECDH efêmero: chave de longo prazo apenas assina, nunca concorda |
| Contador de PIN antes da comparação | Contador descarregado para RRAM antes de subtle::ConstantTimeEq — sem exceções |
| Zeramento de hardware | Sobrescrita multi-passo originada do TRNG; boot0 zera antes da enumeração USB |
| Nenhum segredo no barramento USB | Host desinformado vê apenas armazenamento em massa padrão; nenhuma impressão digital possível |
| Evidência de violação monotônica | Contadores unidirecionais de hardware no domínio sempre ligado |
| Autenticação de três fatores | Posse: token USB; conhecimento: PIN no dispositivo (pin-policy); biométrico opcional não implementado — docs/THREE_FACTOR_AUTH.md |
| Contadores RRAM e trilha de auditoria | HAL monotônico para PIN (e futuras assinaturas PQ com estado); registros de auditoria de perfil e hook de auditoria OpenPGP na RAM — log de auditoria NV somente anexação não implementado — docs/AUDIT_LOG.md, docs/RRAM_LAYOUT.md |
| Operações de tempo constante | Todas as comparações secretas via subtle; verificadas por harnesses dudect |
| test-hal nunca em produção | Exigido pela tarefa xtask check-fw |
| Crate | Papel |
|---|
galdr-core | Traits HAL (MonotonicCounter, HardwareTrng, ZeroiseController, VaultStorage), erros compartilhados, fakes test-hal |
vault | Contratos de cofre RRAM, rótulos KeyPurpose do HKDF, tipos de material de chave (zeroize, sem Clone/Copy) |
pin-policy | Máquina de estados PIN; incremento de contador antes de subtle::ConstantTimeEq; zeramento por limiar |
usb-personality | Personas de armazenamento em massa vs desbloqueio autenticado (incluindo papel de armazenamento em massa falso); desafio/resposta; aplicação de cartão OpenPGP/CCID; desconexão USB ao bloquear |
ephemeral-session | Protocolo de sessão ECDH efêmera autenticada; sigilo de encaminhamento |
cipher-profile | Perfis de cascata de cifras configuráveis pelo usuário; embutidos e definidos pelo usuário |
cess | HKDF-BLAKE3 K_outer, ChaCha AEAD externo, suite_id || inner_blob; veja CESS_CONFORMANCE.md |
biometric-api | Tipos de fio pré-portão biométrico (CBOR, SignedMatchResult), auxiliares de token de sessão |
biometric-vault | Selagem de template e peças de integração do lado do cofre |
biometric-fingervein / biometric-sweet | Esboços de backend biométrico plugáveis |
security-tests | Arneses de temporização dudect para caminhos criptográficos |
host-tools | Hashing de manifesto do host, verificação de atualização, psram-unlock, galdralag-provision (provisionamento Xous de PIN CDC de duas linhas) |
xtask | Construir, verificar, testar, fuzzar, build-and-register (Xous galdralag-service), teste de temporização |
galdra-core-host | Esquema SQLite, contatos/grupos/auditoria/sincronização, busca HKP/WKD/LDAP, auxiliares de dispositivo e host OpenPGP |
galdra | CLI sobre galdra-core-host |
galdrad | Daemon REST local |
galdra-gtk | Interface GTK4 para desktop |
| Comprimento da cascata | Pilhas de cifras distintas ordenadas | × BLAKE3 opcional ativado/desativado em cada uma das comprimento−1 lacunas entre camadas |
|---|
| 1 camada | 5 | 5 × 2^0 = 5 |
| 2 camadas | 20 | 20 × 2^1 = 40 |
| 3 camadas | 60 | 60 × 2^2 = 240 |
| 4 camadas | 120 | 120 × 2^3 = 960 |
| Total | 205 | 1245 |