supermagnum/galdralag-firmwareUm framework criptográfico para Baochip-1x.
Este projeto está registado na Open Invention Network (OIN). A OIN é um pool de patentes defensivo: os membros licenciam cruzadamente patentes relacionadas com Linux para que os participantes possam distribuir e utilizar software de código aberto com menor exposição a patentes.
Estado: A aguardar: https://github.com/betrusted-io/xous-core/pull/937
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 cartão inteligente OpenPGP e um cofre encriptado. Toda a pilha de hardware — RTL, esquemas, bootloader, SO — é de código aberto e auditável.
A especificação de hardware, o modelo de arranque, as tabelas de requisitos e a utilização 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 em modo bootloader para gravação, prima SW2 para alternar (consulte o esquema desse repositório). Notas de arquitetura para este repositório: docs/ARCHITECTURE.md.
A ferramenta de anfitrião Galdra mantém um diretório SQLite local de destinatários (contactos). Cada identidade armazenada inclui material de chave pública mais etiquetas laterais opcionais (consulte a tabela abaixo). Estas etiquetas vivem na base de dados do anfitrião e, para chaves Galdra, no armazenamento de contactos 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. O opcional 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 utiliza SelfAttested, HostVerified, RegistrySync e OobVerified (consulte Comparação de metadados (GnuPG vs Galdra) e o layout do armazenamento de contactos em docs/RRAM_LAYOUT.md).
Detalhes do lado do anfitrião e comportamento da 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 única cascata, cada uma com a sua chave derivada; consulte Capacidades principais), fluxos relacionados com Shamir, ECDH efémero autenticado onde implementado, e ferramentas de anfitrião Galdra). O principal alvo de interoperabilidade é a utilização de cartão OpenPGP estilo GnuPG, não todos os protocolos de token do mercado.
Este firmware não é:
Exclusões a nível de crate alinhadas com as mesmas restrições estão listadas em Crates Explicitamente Excluídos 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 externo, HKDF-BLAKE3 para K_outer e divisão Shamir GF(2^8) byte a byte). A declaração completa de alinhamento, o registo de desvios e o 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 xous-core), compilado com a funcionalidade ccid-openpgp, utilizando crates/baochip-openpgp para a janela OpenPGP RRAM e provisionamento. Layout: docs/RRAM_LAYOUT.md. Lacunas pré-produção (UX de PIN do operador, aprovação do mapa de plataforma): Limitações conhecidas / trabalho em aberto.
O objetivo geral permanece um firmware completo, testado e de código aberto de token de segurança de hardware: comportamento estilo cartão OpenPGP para GnuPG sobre CCID (consulte Compatibilidade OpenPGP e GnuPG), mais funcionalidades adicionais no dispositivo atualmente não definidas pelo padrão de cartão OpenPGP — ECDH efémero com sigilo de encaminhamento, Shamir K-de-N, perfis agnósticos de cifra, volume de chamariz microSD — conforme resumido em Padrões vs. funcionalidades específicas do firmware. Tudo em RTL aberto com um bootloader reproduzível.
Para implementações que precisam de dois tokens físicos separados (ou detentores de partilhas K-de-N) antes de desbloquear servidores, firewalls, cofres de medicamentos ou volumes encriptados, consulte Quórum de chave dupla de hardware (padrão integrador) em Capacidades principais. Cada dispositivo é uma fonte de credenciais; a aplicação do quórum é o seu gateway de acesso, camada PAM ou painel — não este firmware.
O firmware distribuível para Baochip-1x é assinado com Ed25519. Assina a imagem de firmware com uma chave privada Ed25519; o GnuPG pode fazer isto com gpg --sign usando uma subchave de assinatura Ed25519 (o fluxo de trabalho habitual de assinatura destacada OpenPGP, adaptado ao empacotamento que o seu build emitir). A ROM imutável boot0 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. boot1 carrega então imagens de aplicação assinadas (por exemplo blobs UF2 entregues sobre armazenamento em massa USB em modo bootloader). As peças padrão transportam quatro chaves públicas Ed25519 no chip (funções como implementação de código, beta e desenvolvedor); boot0 / boot1 aplicam 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 em xous-core.
Nem todos os testes são executados em todos os comandos; isso é intencional.
xtask não no teste padrão do espaço de trabalho: A receita comum é cargo test --workspace --exclude xtask porque xtask é um crate de orquestração de build. Execute cargo test -p xtask quando quiser os seus testes.#[ignore]: Estes são omitidos a menos que passe --ignored (e quaisquer filtros de crate necessários). As razões incluem: cobertura que já é exercida em testes unitários focados (ex.: zeroização pós-drop), casos lentos (ex.: geração de chaves RSA) e fluxos dependentes de hardware ou token em ferramentas de anfitrião como galdra que precisam de um dispositivo ligado ou fixtures.test-all --no-fuzz: Omite o passo cargo-fuzz para manter CI ou execuções rápidas curtas e para evitar exigir um toolchain nightly para esse passo; execute cargo run -p xtask -- test-all sem --no-fuzz, ou invoque alvos de fuzz separadamente (consulte ).Também se pode verificar a integridade de crates com isto quando o PR estiver 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 utilizando crates criptográficos validados e auditados. As primitivas criptográficas são extraídas exclusivamente de dependências auditadas do espaço de trabalho. Os algoritmos pós-quânticos são limitados por funcionalidade e marcados AUDITORIA INDEPENDENTE PENDENTE. Consulte Estado pós-quântico.
Nota: Partes deste projeto foram desenvolvidas com assistência de IA (Claude, Anthropic). A conceção, as escolhas criptográficas e as decisões de segurança não foram revistas por um criptógrafo profissional. Trate isto como um projeto experimental e aplique o seu próprio julgamento crítico. A revisão independente por especialistas é fortemente recomendada antes de qualquer implementação em produção.
Está pronto para testes por humanos. Você decide se compila ou executa qualquer deste software; pode haver bugs que testes unitários, fuzzing e outras verificações não encontraram. Utilizar 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 de 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 de código escrita à mão como único fluxo de trabalho — inviável sem ferramentas assistidas (por exemplo editores de IA conversacional). Essa restrição é distinta da correção: os revisores devem ainda ponderar testes, fuzzing e auditoria independente conforme documentado noutros pontos desta página.
Um criptógrafo ou implementador sério a rever Galdralag abrirá tipicamente crates/vault/tests/ e crates/cipher-profile/tests/ antes de ler prosa. A suíte 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 que avaliam o projeto para aquisição, decidem se contribuem ou distribuem código sem formação profunda em metodologia de testes criptográficos ainda merecem um ponteiro para a evidência concreta.O que analisar: O material de conformidade inclui exemplos práticos do RFC 8439 para ChaCha20-Poly1305 em crates/vault/tests/rfc_vectors/, JSON Wycheproof incorporado para casos extremos 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 do BLAKE3 (todos os 35 comprimentos de entrada, todos os três modos) em crates/vault/tests/blake3_vectors.json, vetores de especificação do Twofish (1203 casos incluindo Monte Carlo) em crates/vault/tests/twofish_vectors.json, e o fixture KAT da cascata CESS do próprio projeto com intermediários verificados de forma independente em crates/cipher-profile/tests/fixtures/cascade_cess_kat.json. Juntos, estes são a fonte da verdade que o executor e os revisores podem exercitar com cargo test --workspace e python3 scripts/verify_cascade_kats.py.
RFC 8439 é publicado pela Internet Engineering Task Force (IETF), a organização que padroniza grande parte de como a internet interoperabiliza. RFCs (Request for Comments) são a forma usual para especificações de protocolos e muitas especificações criptográficas. O RFC 8439 define a criptografia autenticada ChaCha20-Poly1305 (com base nos projetos de Daniel Bernstein) e inclui exemplos práticos concretos com entradas e saídas esperadas específicas para que implementações independentes possam verificar se correspondem ao padrão byte a byte. O texto simples amplamente reproduzido que começa com Ladies and Gentlemen of the class of '99: wear sunscreen aparece nos exemplos do apêndice do RFC: se o seu código reproduz a saída AEAD exatamente, 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 todos os perfis de cascata multicamada neste firmware, portanto esta verificação está na fundação de toda a pilha de cifras.
Wycheproof é um corpus de testes lançado pela equipe de segurança do Google (2017). O nome refere-se ao Monte Wycheproof na Austrália — frequentemente citado como a menor montanha do mundo — porque o projeto foca em eliminar obstáculos pequenos, mas fatais: estouros de inteiros, casos de fronteira, entradas malformadas e tags de autenticação adulteradas; falhas que aparecem repetidamente em criptografia real implantada. Ele complementa os vetores estilo RFC: exemplos estilo RFC 8439 demonstram correção contra o AEAD publicado; Wycheproof testa robustez onde implementações historicamente quebram. Neste repositório, o JSON 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 Alemão de Segurança da Informação (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 o 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 do BLAKE3 são o corpus de testes oficial publicado junto com a especificação do BLAKE3 por seus autores. Eles cobrem 35 comprimentos de entrada de 0 a 102400 bytes, especificamente escolhidos para exercitar todas as condições de fronteira internas de chunk e hash em árvore que são invisíveis para testes de entrada curta. Todos os três modos do BLAKE3 — hash padrão, hash com chave e derivação de chave — são cobertos. O BLAKE3 é usado em todo este firmware para derivação de chave HKDF e verificações de integridade entre camadas nos perfis de cascata de cifras; a cobertura de fronteiras importa porque a construção em árvore do BLAKE3 só é ativada acima de 1024 bytes.
A suíte de testes também é detecção de adulteração para a cadeia de suprimentos. Todos os primitivos criptográficos neste firmware vêm de crates RustCrypto auditados — nenhuma criptografia é implementada in-tree. Como os vetores de conformidade acima são executados contra esses 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 alcance 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, então mesmo um toolchain Rust comprometido produzindo saída errada é detectado pela verificação cruzada. Esta é uma história de integridade da 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 afirmaçõ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 smart card: 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 para que suas chaves privadas nunca existam desprotegidas no seu computador. No modo camuflagem, ele pode enumerar como armazenamento removível comum com arquivos de aparência inofensiva para que uma olhada rápida não revele seu papel real; veja Camuflagem de armazenamento abaixo.
GnuPG significa GNU Privacy Guard. É a implementação do projeto GNU de 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). Você normalmente o executa como o comando gpg em Linux, BSD, macOS ou Windows; muitos utilitários gráficos de e-mail e chaves o envolvem por baixo.
As pessoas usam GnuPG para:
gpg-agent expõe chaves de autenticação de um smart card ou keystore local.GnuPG e discos criptografados (LUKS). O Linux tem uma forma integrada de criptografar um disco ou partição inteira, chamada LUKS. Uma vez que um disco é criptografado, ele parece ruído sem sentido para qualquer pessoa sem a chave, então um laptop perdido ou roubado não entrega seus arquivos.
Normalmente você desbloqueia esse disco digitando uma senha. O GnuPG permite que você use seu token em vez disso. A ideia é simples: a chave de desbloqueio do disco é ela mesma bloqueada com a chave do seu token. Quando você quer abrir o disco, o token desembaralha essa chave de desbloqueio para você, mas apenas enquanto o token está conectado e você digitou seu PIN. Remova o token, e o disco não pode ser aberto de forma alguma, mesmo no mesmo computador.
Em resumo, isso transforma o token em uma chave física para seu disco criptografado. Configurá-lo (e adicionar uma forma de backup de acesso, caso o token seja perdido) é feito com as próprias ferramentas de disco do Linux; o token simplesmente mantém a chave. Se você preferir compartilhar a capacidade de desbloquear um disco entre várias pessoas, de modo que nenhuma pessoa sozinha possa fazê-lo, veja Compartilhamento de segredo de Shamir e criptografia de disco.
Por padrão, o GnuPG armazena chaves em ~/.gnupg. Com um smart card OpenPGP, as chaves privadas sensíveis vivem no cartão; scdaemon (parte da suíte GnuPG) fala 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 smart cards OpenPGP: assinar e descriptografar e-mail e arquivos, autenticar (por exemplo, SSH quando você usa gpg-agent como de costume) 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 alvo principal de interoperabilidade no host: este firmware implementa a aplicação de cartão OpenPGP sobre CCID, que scdaemon aciona (gpg --card-status, gpg --card-edit e criptografar/assinar/descriptografar normais com chaves no cartão). Outro software que fala os mesmos protocolos de smart card pode funcionar também; comandos, slots, algoritmos e limites atuais de integração estão em Compatibilidade OpenPGP e GnuPG. Quando NFC for ativado 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 quórum 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 para 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 com suporte 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 o invólucro, 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 volta. 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 então 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 de sessões passadas. Essa propriedade é chamada de sigilo perfeito (forward secrecy) 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 para que quaisquer K desses compartilhamentos sejam necessários para reconstruí-la — mas nenhum detentor de um único compartilhamento pode fazer nada sozinho. Isso é chamado de compartilhamento de segredo de 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 integrados dependendo de quanta cautela sua situação exige.
Minha recomendação pessoal é BrainpoolP256r1 + ChaCha20-Poly1305 + BLAKE3. Este é o perfil standard integrado. Ele usa a curva Brainpool P-256 da BSI para acordo de chave efêmero, ChaCha20-Poly1305 para criptografia simétrica e BLAKE3 para derivação de chave e integridade entre camadas. É rápido, bem testado, amigável à 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 nenhum primitivo projetado pela 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 dos órgãos de padronização governamentais. AES e a suíte NIST são intencionalmente excluídas. 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. A Camellia foi avaliada independentemente pelo projeto NESSIE da UE e pelo programa CRYPTREC do Japão, e é especificada no RFC 3713 e ISO/IEC 18033-3.
Um PIN errado bloqueia você adequadamente. O token conta tentativas de PIN com falha 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 material sensível.
O que ele ainda não faz. Não há hardware disponível ainda — este é 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, não comportamento entregue ainda. 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.
O Galdralag pode trabalhar com dois tipos diferentes de chave assimétrica ao mesmo tempo. Eles 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 detalhe; 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 puro. 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 reivindicação de identidade é genuína; esse grafo social é a base da web of trust descrita em Web of Trust e Festas de Assinatura de Chaves mais adiante neste README. Quando o Galdralag atua como um smartcard OpenPGP, ele mantém o material de chave privado no chip e realiza assinatura e descriptografia lá. A chave pública, os User IDs e as assinaturas de outros vivem no host e são gerenciados pelo GnuPG da maneira usual. O token não altera o formato de mensagem OpenPGP no fio; o GnuPG o trata como qualquer outro cartão OpenPGP.
Uma chave Galdra é um par de chaves assimétrico puro — Ed25519, X25519 ou uma das curvas Brainpool ou NIST que o firmware suporta. Os bytes da chave em si não carregam reivindicações de identidade: sem pacotes User ID, sem e-mail embutido, sem assinaturas de 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 do armazenamento 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 e User ID normais (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 sidecar estruturados para contatos operacionais (detalhe completo no host e no chip em Metadados de contato Galdra). Um travessão significa que essa pilha não tem campo padrão e separado para esse item.
O OpenPGP coloca nome e e-mail em uma única string User ID; ele 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.
Tokens atualizados de firmware que oferecia BrainpoolP512r1 podem ainda retornar atributos P-512 em GET DATA; operações GnuPG nesses slots então falham com erros genéricos de cartão. Execute galdra device status (ou veja docs/OPENPGP_CARD.md) para identificar slots obsoletos; o histórico de remoção está em CHANGELOG.md.
| PW1 / PW3 | Nunca armazenado | Verificador no chip (mín. 5 caracteres, 3 tentativas padrão) |
| DOs do titular do cartão (login, idioma, URL, …) | Em cache pelo GnuPG | Opcional (254 bytes máx. por DO) |
Aplicação de cartão 3.4.1, CCID e fluxos de trabalho GnuPG: docs/OPENPGP_CARD.md e Compatibilidade OpenPGP e GnuPG.A divisão existe porque as informações de identidade que importam nas comunidades que a Galdralag atende — indicativo, ID DMR, afiliação a rede de rádio — não têm um lugar natural em um User ID do OpenPGP. Um User ID é feito para nome e e-mail. Escrever algo como LA5XYZ <[email protected]> DMR:2345678 em uma string de User ID é informal, não estruturado e não legível por máquina de nenhuma 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 host e o armazenamento no chip entendem nativamente.
Na prática, um único dispositivo pode conter ambos os tipos de chave sem conflito. O aplicativo de cartão OpenPGP atende ao GnuPG por meio dos slots padrão SIG, DEC e AUT. O armazenamento de contatos conté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 de crachá. Os dois caminhos não interferem um no outro.
Se alguém tem 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 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 campo de indicativo ou 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 com a qual você se importa.
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.
Cada dependência é classificada como inalterada upstream (crates.io como publicada), alterada ou vendida no repositório (cópia fixada ou patch de workspace), ou criada por este projeto (crates de firmware, host e ferramentas). O inventário completo, as funções e o grafo de dependências estão em docs/CRATE_DEPENDENCIES.md.
Uma grande parcela dos bugs relevantes para segurança em bases de código da indústria vem de insegurança de memória (estouros de buffer, use-after-free, desreferências nulas e similares). O MSRC da Microsoft relatou repetidamente que aproximadamente 70% dos CVEs abordados em seus próprios produtos se enquadram nessa 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 importam.
Em Rust seguro (o padrão), o borrow checker elimina corridas de dados e os erros de memória usuais de comportamento indefinido em tempo de compilação sem depender de coleta de lixo. Rust inseguro 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 ownership 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 grep a 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 de lógica, como um loop apertado que desgasta a flash, ou a escolha de valores de registradores errados. Esses continuam sendo preocupações de engenharia e revisão.
Esta base de código aplica padrões comuns de Rust para segredos; eles não são automáticos para todo tipo:
zeroize::Zeroize / ZeroizeOnDrop limpam buffers ao serem descartados; os chamadores optam por isso.subtle::ConstantTimeEq (e similares) onde o tempo importa — == comum não é magicamente de tempo constante.Copy em wrappers de segredos reduz duplicação acidental; a separação de domínio usa tipos distintos e rótulos HKDF (Política de dependências criptográficas).catch_unwind ou abort onde sua plataforma exigir garantias mais fortes.unsafe deve ser escrito explicitamente 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ências criptográficas — nem toda dependência vem de um único projeto guarda-chuva. Para a lista completa de crates e se cada dependência é inalterada, alterada/vendida ou de autoria do projeto, veja docs/CRATE_DEPENDENCIES.md.
Rust não remove deadlocks (por exemplo, locks Mutex mal ordenados), bugs de lógica, protocolos incorretos, desgaste de flash por loops ruins, ataques físicos (glitching, análise de potência) ou riscos de uma compilação correta da imagem errada. Também não garante execução de tempo constante em todo hardware sem codificação cuidadosa. Essas áreas dependem de design, revisão, testes e das práticas de criptografia e cadeia de suprimentos do projeto descritas em outras partes deste README.
Verificação (testes e fuzzing): Além da linguagem, este repositório usa testes de unidade, 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 o seu ambiente; uma máquina virtual é opcional, mas limita o raio de impacto na sua máquina.
Qualquer plataforma de 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 build é 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, aplicam-se as instruções de compilação padrão. A VM pode
ser **fotografada (snapshot)** antes de cada experiência e **revertida (rollback)** de forma limpa se
algo correr mal.
### Avaliação de risco e implementação
**Em última análise, se este firmware é seguro para implementar no seu
ambiente é uma decisão que só você pode tomar**, com base na sua própria
avaliação de risco, na sensibilidade daquilo que está a proteger e
se opta por aguardar uma auditoria independente de terceiros
antes da implementação. Este projeto visa dar-lhe todas as
informações necessárias para tomar essa decisão por si próprio.
Uma lista estruturada de ativos, ameaças **T1–T14**, não-objetivos explícitos e lacunas de verificação do Q2 está em **[docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREAT_MODEL.md)**.
---
## Sobre o nome
**Galdr** é a prática nórdica antiga de magia falada ou cantada: encantamentos
usados para ligar, proteger ou revelar. Nas sagas, nomeia o ato de lançar
o feitiço em si, não apenas as palavras. Por 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 noutros achados do Futhark Antigo.
**Galdralag** é a forma métrica usada para galdr: verso estruturado, preciso,
sujeito a regras, no qual o padrão faz 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
só era conhecido por aqueles que o compreendiam.
---
## Documentação
**Glossário:** [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GLOSSARY.md) — termos explicados em **linguagem simples** (ordenados de A–Z). Comece aqui se o README ou outros documentos parecerem repletos de jargão.
**Depuração:** [docs/DEBUG_INSTRUCTIONS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DEBUG_INSTRUCTIONS.md) — backtraces, restringir `cargo test`, atalhos `xtask`, verificações triplas do firmware, fuzzing e o que recolher antes de reportar um problema.
**Assistentes de IA (Claude, Cursor):** [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/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/main/.cursor/rules).
**Explorar todos os ficheiros:** [github.com/Supermagnum/Galdralag-firmware — `docs/`](https://github.com/Supermagnum/Galdralag-firmware/tree/main/docs)
**Hardware (dongle USB e relacionado):** Duas árvores KiCad: [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-files-usb) — `dabao_v3c` (token USB-A **sem** micro-SD); e [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card) — `dabao_v3c_sdcard` (mesmo layout base **com** suporte para micro-SD), gerbers, BOM, saídas de produção e [documentação de pinout](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card/docs/pinout/README.md). O layout da PCB do dongle USB-A (token mínimo vs avaliação em formato Pico) está descrito em [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md).
| Documento | Descrição |
|----------|-------------|
| [Hardware/kicad-files-usb/](https://github.com/supermagnum/galdralag-firmware/blob/main/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/main/docs/USB_DONGLE_PCB.md) |
| [Hardware/kicad-sd-card/](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card) | Projeto KiCad **dongle USB** `dabao_v3c_sdcard` (suporte para micro-SD); gerbers, BOM, pinout em [docs/pinout](https://github.com/supermagnum/galdralag-firmware/blob/main/Hardware/kicad-sd-card/docs/pinout/README.md); complementa [USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md) |
| [docs/CODE_MAP.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CODE_MAP.md) | **Índice de funções e módulos** do workspace (`pub fn` / tipos por ficheiro com âncoras de linha) |
| [docs/CRATE_DEPENDENCIES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CRATE_DEPENDENCIES.md) | Crates Rust **upstream vs projeto** e como dependem uns dos outros |
| [docs/API_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/API_REFERENCE.md) | Mapa de código + **anexo** para IETF/I-D/GnuPG/Sequoia: construção Shamir GF(256), armour GALDRA SHARE, formato de fio ECDH efémero, etiquetas HKDF, pré-imagens; rotas `galdrad`; dicas de rustdoc |
| [docs/ARCHITECTURE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/ARCHITECTURE.md) | Arquitetura de firmware de alto nível e subsistemas principais |
| [docs/AUDIT_LOG.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/AUDIT_LOG.md) | Registos de auditoria de perfil (`cipher-profile`), hook OpenPGP `OpenPgpAudit`; **sem** registo RRAM append-only implementado ainda |
| [docs/BIOMETRIC_API.md](https://github.com/supermagnum/galdralag-firmware/blob/main/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/main/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/main/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/main/docs/FINGERVEIN_DEVICE.md) | Dispositivo aberto de veia do dedo ESP32-CAM: hardware, esboço de protocolo, vivacidade |
| [docs/SWEET_PLATFORM_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/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/main/docs/GALDRA-TOOL.md) | Ferramentas de anfitrião (`galdra`, `galdrad`, `galdra-gtk`): fluxos de trabalho, aprovisionamento, política de PIN, comportamento operacional |
| [Supermagnum/Fulla](https://github.com/Supermagnum/Fulla) | **Fulla**: registo de chaves públicas OpenPGP orientado para WoT (repositório e implementação do servidor). **Ainda não está a correr nenhuma instância pública do registo**; está planeada uma. **`galdra keyserver push`** / **`galdra keyserver fetch`** e a configuração opcional **`[keyserver]`** visam este ecossistema — veja também [Web of Trust e Key Signing Parties](#web-of-trust-and-key-signing-parties). Notas de design suplementares permanecem em [docs/server.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/server.md). |
| [docs/GLOSSARY.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GLOSSARY.md) | **Glossário em linguagem simples** (A–Z) para leitores não técnicos; o detalhe técnico permanece nos documentos ligados |
| [CLAUDE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/CLAUDE.md) | Instruções para **Claude** / agentes de codificação de IA; aponta para [`.cursor/rules/`](https://github.com/supermagnum/galdralag-firmware/blob/main/.cursor/rules) para **Cursor** |
| [docs/GALDRALAG_DEV_REFERENCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRALAG_DEV_REFERENCE.md) | Toolchain, comandos `xtask`, pontos de entrada de teste de fuzzing e criptografia |
| [docs/dev-ref.md](https://github.com/supermagnum/galdralag-firmware/blob/main/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/main/docs/DEBUG_INSTRUCTIONS.md) | Depuração: `RUST_BACKTRACE`, compilações verbosas, testes limitados, receitas `xtask`, verificações de alvo embebido, indicações de fuzzing, verificações de anfitrião OpenPGP |
| [docs/KEY_LIFECYCLE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/KEY_LIFECYCLE.md) | Geração de chaves, importação, política de exportação, rotação, zeroização, Shamir (conforme refletido em `vault` / OpenPGP) |
| [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md) | Aplicação de cartão OpenPGP, configuração de anfitrião GnuPG/CCID, slots de chaves, algoritmos, udev |
| [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md) | Sistema de perfis de cifra e configuração |
| [docs/DUAL_KEY_QUORUM.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DUAL_KEY_QUORUM.md) | Quórum de duas (ou N-) chaves de hardware como padrão de extensão de integrador sobre Shamir e OpenPGP; não imposto pelo firmware |
| [docs/CIPHER_PROFILE_SECURITY.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILE_SECURITY.md) | Considerações de segurança: identificadores de perfil em texto claro, análise de tráfego, justificação do invólucro externo BrainpoolP384r1, identificadores cifrados, propriedade de curinga |
| [docs/CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CESS_CONFORMANCE.md) | Alinhamento com [CESS](https://github.com/Supermagnum/CESS/tree/main): layout de fio Modo A, `suite_id` de [ALGORITHM-REGISTRY.md — tabela de consulta](https://github.com/Supermagnum/CESS/blob/main/ALGORITHM-REGISTRY.md#cipher-suite-identifier-lookup-table), registo de desvios (AES/SHA-2 retidos vs CESS-CORE), roteiro |
| [crates/cess](https://github.com/supermagnum/galdralag-firmware/blob/main/crates/cess) | CESS Modo A: HKDF-BLAKE3 (`derive_k_outer`, `hkdf_blake3`), selo/abertura externo ChaCha, layout `suite_id \|\| inner_blob`; veja [CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CESS_CONFORMANCE.md) |
| [docs/EPHEMERAL_SESSION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/EPHEMERAL_SESSION.md) | Protocolo de sessão ECDH efémera autenticada |
| [Supermagnum/CESS](https://github.com/Supermagnum/CESS) | **CESS** (*Cryptologically Enchanted Shamir's Secret*) — especificação aberta (texto normativo e vetores de teste) para partilha de segredos por limiar com cifragem autenticada, encapsulamento de partilhas baseado em palavra-passe e troca de chaves híbrida pós-quântica opcional; separado deste firmware mas no mesmo espaço de design que Shamir e os perfis de cifra aqui |
| [docs/PQ_SIGNATURES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/PQ_SIGNATURES.md) | Assinaturas pós-quânticas com estado (XMSS, LMS/HSS), controlo de funcionalidades |
| [docs/Psram.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/Psram.md) | Volume de isco microSD opcional e comportamento relacionado |
| [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/RRAM_LAYOUT.md) | RRAM no chip de **4.194.304 bytes**: offsets do cofre a partir do código-fonte, mapeamento HAL, notas de desgaste / zeroização |
| [docs/TEST_RESULTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/TEST_RESULTS.md#run-metadata) | Abre em **Run metadata**; resumo do pipeline, vetores, dudect, cargo-fuzz ([Secção 6](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/TEST_RESULTS.md#6-cargo-fuzz-libfuzzer)), ciclo de vida das chaves |
| [docs/THREE_FACTOR_AUTH.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREE_FACTOR_AUTH.md) | Token + PIN + biométrico opcional: o que este repositório implementa vs placeholder; esboço de ameaça |
| [docs/THREAT_MODEL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/THREAT_MODEL.md) | Modelo de ameaças: ativos, ameaças T1–T14, o que é e não é defendido, itens não verificados pendentes de hardware Q2, estado da auditoria |
| [docs/PERFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/PERFORMANCE.md) | Notas de desempenho |
| [docs/HARDWARE_BRINGUP_TEST_PLAN.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_BRINGUP_TEST_PLAN.md) | Bring-up do primeiro hardware Q2: imagem com `galdralag-service`, libccid `1D50:6197`, ATR → APDUs `gpg --card-status`, PINs de laboratório Dabao (não CDC em `dabao-ccid`) |
| [docs/XOUS_CORE_UPSTREAM_REQUESTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/XOUS_CORE_UPSTREAM_REQUESTS.md) | Alterações que pertencem ao xous-core (documentos Persona A, política ATR, notas cratespec); Galdralag não aplica patches nessa árvore |
| [docs/HARDWARE_VERIFICATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_VERIFICATION.md) | Zeroização de hardware: verificação por simulação vs silício |
| [docs/HARDWARE_TEST.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/HARDWARE_TEST.md) | Notas de teste orientadas para hardware |
| [docs/NFC_PN532_INTEGRATION.md](https://github.com/supermagnum/galdralag-firmware/blob/main/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/main/docs/SDMMC_STORAGE_INTEGRATION.md) | `embedded-sdmmc` + microSD SPI como armazenamento em massa opcional; alternativa BOM ao PSRAM |
| [docs/USB_DONGLE_PCB.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/USB_DONGLE_PCB.md) | Como fazer uma PCB de dongle USB-A a partir da referência Dabao: a avaliação em formato Pico é para bring-up do firmware; isto remove o header GPIO para um token mínimo; KiCad, FreeCAD, 5 V / 500 mA vs USB-C PD, roteamento QSPI PSRAM |
Os mesmos caminhos resolvem 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/main/docs/OPENPGP_CARD.md)). Essa é a mesma classe de dispositivo que o GnuPG utiliza para **smart cards OpenPGP** através de **CCID/USB**: o anfitrião precisa de uma stack normal de smart cards (`pcscd`, controladores `ccid`, `scdaemon` do GnuPG). **Não é necessário nenhum controlador criptográfico personalizado no lado do anfitrião** além do que usaria para qualquer cartão OpenPGP.
**O que isto permite no anfitrião (assim que o dispositivo estiver visível como leitor CCID):**
| Área | Notas |
|------|--------|
| **Fluxos de trabalho GnuPG** | `gpg --card-status`, `gpg --card-edit`, cifrar/decifrar e assinar usando chaves no cartão |
| **SSH** | `gpg-agent` com `enable-ssh-support` e a configuração habitual `SSH_AUTH_SOCK` |
| **Correio e ficheiros** | Clientes que usam GnuPG (ex.: Thunderbird, Evolution, Kleopatra) e cifragem padrão de ficheiros com `gpg` |
| **Outras ferramentas** | Qualquer coisa que fale OpenPGP card + CCID da mesma forma que o GnuPG |
**Slots de chaves (padrões típicos):** **SIG** (assinatura), **DEC** (decifragem / ECDH), **AUT** (autenticação, ex.: SSH). Os algoritmos operacionais por slot são curvas Brainpool, NIST P-256/P-384 e Ed25519 / X25519. Os atributos de algoritmo RSA podem ser armazenados via PUT DATA, mas GENERATE, PSO:CDS e PSO:DECIPHER falham todos para slots configurados com RSA. A tabela completa e o comportamento de `key-attr` estão em [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md).
**Não coberto pelo cartão OpenPGP / GnuPG aqui:** **WebAuthn / FIDO2** é um protocolo diferente e está fora do âmbito 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 chaves e operações no cartão através de CCID. **O GnuPG** usa isso através de `scdaemon`. O **formato de mensagem OpenPGP** para ficheiros e correio (RFC 4880 e sucessores) é uma camada **do lado do anfitrião**: o cartão fornece as chaves; o GnuPG ainda aplica o formato de mensagem no PC. Nem a especificação do cartão nem a RFC 4880 definem **partilha Shamir**, **sessões ECDH efémeras** ou **perfis de cifra** — essas são [funcionalidades específicas do firmware](#standards-vs-firmware-specific-features).
**Estado da integração:** A lógica OpenPGP e CCID vive em **`usb-personality`**, **`baochip-openpgp`** e no serviço **Xous** **`usb-bao1x`** (veja **xous-core** em **`feature/usb-bao1x-ccid-openpgp`**). O opcional **`galdralag-service`** (`services/galdralag`) liga-se a **`usb-bao1x`** para IPC **CCID** e responde a APDUs **XfrBlock**; as imagens Dabao precisam dele via cratespec (`scripts/build_dabao_ccid_image.sh`). A BaoSec pode ainda fazer a ponte de **PDDB** para **RRAM**. Detalhes: [services/galdralag/README.md](https://github.com/supermagnum/galdralag-firmware/blob/main/services/galdralag/README.md). Layout de memória: [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/RRAM_LAYOUT.md). **GnuPG de ponta a ponta em hardware real** ainda precisa de uma imagem completa com Galdralag, reconhecimento do **`1D50:6197`** pelo **libccid** do anfitrião e itens em [Limitações conhecidas / trabalho em aberto](#known-limitations--open-work).
## Sessão do token e exportação de chaves
**Desligamento físico (desligar):** O anfitrião perde o dispositivo USB; qualquer operação em curso falha até o token ser ligado novamente e reenumerado. No dispositivo, a **sessão de cartão** OpenPGP é limpa: o **estado de verificação de PIN** não sobrevive a desligamento ou remoção, pelo que **assinatura, decifragem e outras operações protegidas exigem VERIFY PIN novamente** após religar, como noutros smart cards OpenPGP. **O material de chave privada permanece armazenado no token** no armazenamento selado do cofre; desligar não o apaga, a menos que um caminho separado de **zeroização** ou limpeza seja executado.
**O que pode sair do dispositivo:** Por design, **apenas material de chave pública** é permitido atravessar a ligação USB (por exemplo, pacotes de chave **pública** OpenPGP e dados relacionados que a especificação do cartão expõe ao anfitrião). **Chaves privadas**, escalares secretos em bruto e blobs de chaves selados **não** saem do dispositivo através dos caminhos normais do firmware; as operações com chave privada são executadas **no token**. O anfitrião recebe **resultados criptográficos** (assinaturas, texto claro decifrado para fluxos de trabalho de decifragem assistida por cartão) onde os comandos padrão o exigem, não uma cópia portátil da chave privada.
**Importar 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 de anfitrião para carregar esses slots estão descritas em [docs/GALDRA-TOOL.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GALDRA-TOOL.md) à medida que a integração amadurece.
---
## Web of Trust e Key Signing Parties
O OpenPGP e o **GnuPG** usam um modelo de confiança descentralizado — a **web of trust** — para ajudar a verificar quem possui quais chaves e se deve confiar numa determinada **chave pública**. Esse modelo é inteiramente **do lado do anfitrião**. Onde atestações suportadas por chip, como [eID alemão e Governikus](#german-eid-and-governikus-as-a-trust-anchor-for-public-keys), não estão disponíveis ou são inadequadas, é a alternativa descentralizada habitual (**key signing parties**, assinaturas em certificados); onde **estão** disponíveis, ambas as abordagens podem coexistir como caminhos complementares.
**Fingerprint Galdralag (`G:`):** Para fluxos de trabalho de verificação presencial, **Galdra** pode mostrar um fingerprint **vinculado ao dispositivo** derivado da chave pública **SIG** do token (**BLAKE3-160**, prefixo `G:`). **Não** é um fingerprint de certificado OpenPGP v4. Está **apenas** disponível quando o **perfil de cifra** ativo tem **`ephemeral_ecdh: false`**; os perfis incorporados têm por padrão **`ephemeral_ecdh: true`**, pelo que normalmente adiciona um perfil de utilizador com **`galdra profile add ... --no-ephemeral-ecdh`** para fluxos de trabalho que precisam deste identificador juntamente com assinatura de anfitrião estilo **WoT**. Definição em linguagem simples e especificação de formato: [Fingerprint Galdralag](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/GLOSSARY.md#g). Ciclo de vida, política de rotação e o portão ECDH efémero: [KEY_LIFECYCLE.md — Fingerprint Galdralag](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/KEY_LIFECYCLE.md#galdralag-fingerprint-host).
### Obter o seu fingerprint Galdralag
O anfitrião imprime uma string que **começa sempre 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/main/docs/GALDRA-TOOL.md)** no anfitrião e garanta que **PC/SC** funciona (**`pcscd`**, **`libpcsclite`**) para que a ferramenta possa falar CCID com o token (veja [Compilar e instalar ferramentas de anfitrião](#compile-and-install-host-tools-galdra-galdrad-galdra-gtk)).
2. Ligue o token (desbloqueie se o seu fluxo de trabalho o exigir).
3. Selecione um **perfil de cifra** com **`ephemeral_ecdh: false`**. Confirme com **`galdra profile show <name>`** (`ephemeral_ecdh: off`). O nome de perfil padrão **`standard`** normalmente tem **`ephemeral_ecdh: on`**; crie um com **`galdra profile add <name> ... --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 OpenPGP incluem um esquema de verificação de certificados para auxiliar na verificação da propriedade de chaves; sua operação é chamada de teia de confiança. Certificados OpenPGP (uma ou mais chaves públicas mais material de ID do proprietário/usuário) podem ser assinados digitalmente por outros usuários 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 host, ou carregada em um token compatível com OpenPGP).Uma festa de assinatura de chaves é um encontro presencial onde os participantes trocam impressões digitais de chaves e verificam a identidade uns dos outros antes de assinar certificados posteriormente.
Características típicas:
Isso gera um grafo social: se Alice confia em Bob e Bob assinou a chave de Charlie, Alice pode optar por confiar na chave de Charlie dependendo da profundidade de confiança e da política.
Por que esses eventos importam:
As festas geralmente evitam computadores durante a troca de identidade, para que atacantes tenham menos chances de inserir chaves substituídas ou malware em máquinas compartilhadas.
Antes do evento. Calcule e registre sua impressão digital (um resumo derivado de hash da chave pública—curto o suficiente para comparar de forma confiável). Não dependa de trocar chaves completas em papel nesta fase, a menos que seus organizadores especifiquem o contrário.```bash
gpg --fingerprint YOUR_KEY_ID
Traga a impressão digital em papel ou outro meio durável (formato de exemplo: `ABCD 1234 EFGH 5678 90AB CDEF 1234 5678 90AB CDEF`).
**No evento (apenas impressões digitais).** Troque **impressões digitais**, verifique os IDs e anote quais impressões digitais pertencem a qual pessoa verificada. Confirme se a identidade declarada de cada participante corresponde aos documentos verificados.
**Após o evento.** Obtenha as **chaves públicas** completas de **servidores de chaves** ou por distribuição direta; confirme se as chaves baixadas correspondem às **impressões digitais** registradas em papel; **assine** as chaves que você verificou; opcionalmente, **envie** as assinaturas para que outras pessoas possam usá-las.
### Impressões digitais em vez de chaves completas no evento
- **Segurança operacional.** Mantém ataques de substituição vinculados a impressões digitais verificadas, em vez de confiar em máquinas arbitrárias durante o evento.
- **Simplicidade.** Impressões digitais cabem em 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 **ID de usuário**, **ID de chave** ou **impressão digital** e sustentam a distribuição em larga escala para a teia de confiança.
Como eles se comportam em princípio:
- **Replicação distribuída.** Enviar para um servidor que participa de uma malha de sincronização geralmente propaga para os pares (pools clássicos no estilo **SKS** funcionavam assim).
- **Sincronização.** Novas chaves, assinaturas e certificados de revogação se espalham de acordo com a política e a conectividade de cada servidor.
- **Acesso público de leitura.** Apenas material **público** é destinado à publicação; **chaves privadas** nunca devem ser enviadas.
**Privacidade.** Chaves publicadas expõem **IDs de usuário** (frequentemente incluindo endereços de e-mail). Trate os envios como **públicos e de longa duração** em muitos servidores; envie **certificados de revogação** quando uma chave precisar ser aposentada. A política varia conforme o operador ([keys.openpgp.org](https://keys.openpgp.org/) difere dos pools legados).
**Topologia de pares.** Gráficos das 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).
### Usando 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; a 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 o comportamento autoritativo do 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, além de rótulos opcionais de radioamador, dicas postais, organisation (grafia JSON), role, note, badge_number, phone_number e colunas relacionadas alinhadas aos metadados de contato do Galdra. galdra keyserver push envia JSON POST /api/v1/keys (incluindo armored_public_key, email e esses campos opcionais quando você passa flags de CLI); galdra keyserver fetch e a estrofe de configuração [keyserver] são implementados em / nessa direção. ; espera-se um serviço operado publicamente no futuro. Prosa adicional de design histórico vive em .
Diferentes partes deste projeto alinham-se a diferentes padrões. A interoperabilidade com GnuPG limita-se ao que a aplicação de cartão OpenPGP e o CCID definem. Outros recursos são implementados no firmware (e às vezes nas ferramentas de host Galdra), mas não são algo que você possa invocar por meio de fluxos de trabalho padrão de cartão gpg.
Para o comportamento diário do cartão, confie em docs/OPENPGP_CARD.md. Para recursos somente de cofre ou exclusivos de 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. O SSS ainda é útil junto com a criptografia normal: ele quase nunca substitui a cifra simétrica no disco — ele protege o pequeno segredo (chave mestra ou senha) que desbloqueia essa criptografia.
Padrão (sempre a mesma ideia):
1. LUKS (Linux) e SSS externo
O LUKS criptografa o volume com uma chave mestra. Você pode extrair essa chave (ou um segredo de key-slot, dependendo do seu procedimento), dividi-la com uma ferramenta SSS e armazenar as partes separadamente. No momento do desbloqueio, combine K partes, reconstrua o material de chave e forneça-o ao cryptsetup (veja a documentação da sua distribuição; o manuseio incorreto de chaves pode bloquear o acesso).
Exemplo de formato 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**
O [Vault](https://www.hashicorp.com/products/vault) usa Shamir para **deselar (unseal)**: a chave de criptografia de armazenamento é dividida na inicialização (ex.: 3-de-5 operadores, cada um detém uma parte). Após um reinício, **K** partes devem ser inseridas para deselar. O mesmo padrão **K-de-N sobre um segredo mestre** do 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 no dispositivo. A mesma **camada** se aplica se você a alinhar com criptografia em massa:
- Gere uma chave mestre aleatória de 256 bits (ou apropriada).
- Criptografe a unidade ou o armazenamento em massa com **AES-GCM** ou **ChaCha20-Poly1305** usando essa chave (isso corresponde às crates simétricas auditadas do workspace).
- Use `vsss-rs` para dividir a chave mestre em **N** partes com limite **K**.
- Armazene as partes em slots do vault, outros dispositivos ou com detentores de chave.
- Na inicialização ou recuperação, colete **K** partes, reconstrua e, em seguida, use **HKDF** (ou sua política) para subchaves separadas por domínio, se necessário.
**4. VeraCrypt**
O VeraCrypt não implementa SSS internamente. O mesmo padrão **externo** se aplica: divida a **frase secreta ou o material do arquivo de chave** com uma ferramenta SSS; não tente dividir o texto cifrado do volume com Shamir.
### 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 camada 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á empilha: aes-gcm / chacha20poly1305 para dados em repouso, vsss-rs para dividir o segredo mestre, hkdf para derivação após a reconstrução.
| Decisão | Opções típicas |
|---|
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 os modelos de ameaça para o seu ambiente.
Autorização de duas chaves de hardware / quórum (exigindo dois tokens físicos separados
ou detentores de partes antes de uma operação crítica) é um padrão de extensão suportado,
não um recurso de firmware. O Galdralag fornece primitivas Shamir K-de-N
(vault::shamir, galdra shamir)
e autenticação OpenPGP de token único; um wrapper LUKS downstream, painel de acesso
ou daemon personalizado deve impor quórum, janelas de sessão e reconstrução segura.
Esse limite, fluxos de trabalho de referência 2-de-N e notas de segurança para
integradores estão em docs/DUAL_KEY_QUORUM.md. Isso é
possível com as primitivas existentes hoje; a orquestração é intencionalmente deixada para
o consumidor — não um compromisso de roadmap deste repositório.
Um padrão concreto é uma unidade ou volume criptografado usando curvas Brainpool onde sua pilha as exige (por exemplo, ECDH/ECDSA em torno de um segredo mestre), combinado com Compartilhamento de Segredo de Shamir no material de chave que desbloqueia essa criptografia (a mesma camada de pequeno segredo acima: SSS protege a chave, não o texto cifrado de vários gigabytes). Se e quando firmware e software de host que implementam esse fluxo de trabalho forem auditados de forma independente, tal combinação pode ser valiosa para organizações que precisam atender a políticas de quórum e perfis nacionais de criptografia ao mesmo tempo.
Por que as curvas Brainpool (ex.: BrainpoolP256r1, BrainpoolP384r1) são frequentemente discutidas nesse contexto:
Cenários em que combinar SSS com criptografia de 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 nacional de eID suportada por chip comparável não estiver disponível ou for impraticável para sua jurisdição ou fluxo de trabalho, Web of Trust e Festas de Assinatura de Chaves descreve uma abordagem alternativa no lado do host 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 (Escritório Federal de Segurança da Informação da Alemanha). Após o remetente se autenticar com um cartão de identificação compatível com 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 Usuário 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 host, conclua o fluxo de envio do Governikus incluindo autenticação eID (normalmente AusweisApp e leitura de cartão NFC) e use a chave pública assinada retornada pelo serviço (por exemplo, de distribuição por e-mail). A chave privada permanece no Galdralag durante todo o processo.
Nenhum caminho substitui o outro. O eID e a etapa do Governikus vinculam a chave pública à identidade verificada contra o chip no momento do envio; eles não fornecem sigilo de encaminhamento, 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 em outro lugar neste README. O chip eID e o processo de emissão ao redor também não implementam, por si só, o comportamento de ECDH efêmero e em cascata do token. Por outro lado, uma chave OpenPGP Brainpool gerada no dispositivo está alinhada com o contexto de implantação BSI/UE já discutido para uso institucional de Brainpool, mas sem uma etapa de atestação externa, os correspondentes devem confiar em outros meios para conectar uma impressão digital a uma pessoa jurídica.
| Camada | Papel |
|---|---|
| Chave pública OpenPGP (ex.: Brainpool no Galdralag) | Estrutura criptográfica e controle de chave privada no token; as escolhas de curva seguem expectativas de classe BSI TR-03111 (veja as e a discussão TR-03111 em ) |
Limitação: A verificação é baseada em nome. Se duas pessoas compartilham o mesmo nome legal nos campos que o serviço compara, a atestação não as distingue; ela confirma vínculo de identidade àquele nome no momento da atestação, não unicidade global. Preocupações rotineiras do OpenPGP (vínculo de e-mail, rotação de chaves, revogação) permanecem em vigor.
Alinhamento de políticas: o mesmo BSI que define orientações técnicas relacionadas a Brainpool (BSI TR-03111; vetores de conformidade em crates/vault/tests/bsi_vectors/) também está por trás do processo de assinatura eID do Governikus, o que muitas vezes importa em ambientes alemães e da UE onde Brainpool já é exigido ou preferido — veja Shamir mais Brainpool: exemplo e adequação institucional.
Escopo mais amplo (nota de pesquisa, não um levantamento concluído): O mesmo padrão — vincular uma chave pública OpenPGP à identidade verificada por chip — é aplicável em princípio onde quer que exista eID nacional; quais provedores oferecem uma etapa de assinatura semelhante à do Governikus, e sob quais regras, é uma questão separada que vale a pena investigar à medida que as implantações se expandem. Outros estados membros da UE executam ecossistemas de eID baseados em cartão sob o eIDAS que podem suportar âncoras de confiança comparáveis ou mais fortes do que o caminho alemão sozinho; este README não os cataloga.
Estônia e Bélgica adotaram NIST P-384 no chip em vez de Brainpool, enquanto o perfil BSI do setor público alemão se centra em Brainpool (veja acima). O Galdralag já suporta Brainpool e NIST P-256/P-384 no cartão OpenPGP (docs/OPENPGP_CARD.md); RSA neste repositório é um auxiliar de biblioteca galdr-vault, não um slot de cartão funcional (Assimétrico / acordo de chave). 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 ele é restrito a pessoal federal e está em X.509/FPKI, não integrado ao OpenPGP; o Canadá não tem um cartão nacional de assinatura 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 recursos específicos do firmware) precisariam impulsionar mudanças de padrões e implementação em outro lugar. Este repositório não fala pela IETF ou GnuPG; os locais abaixo são onde tais emendas são normalmente perseguidas.
CESS — Cryptologically Enchanted Shamir's Secret — é um padrão criptográfico aberto para compartilhamento de segredo com limiar juntamente com criptografia autenticada independente de cifra, empacotamento de partes baseado em senha e troca de chaves híbrida pós-quântica opcional. O repositório CESS contém a especificação normativa, o registro de algoritmos, vetores de teste e o executor de conformidade.
Este firmware está em conformidade com o CESS para as construções implementadas aqui: as regras interoperáveis de partes e envelope da especificação ficam ao lado dos mesmos temas de Shamir, Brainpool e perfil de cifra descritos em outro lugar neste 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 roadmap para interoperabilidade mais forte): docs/CESS_CONFORMANCE.md.
Se os mantenedores deste repositório GitHub não responderem a issues, pull requests ou e-mails, você ainda pode avançar novas cifras, comportamento OpenPGP e trabalho relacionado a padrões no ecossistema mais amplo. Sequoia PGP é uma pilha OpenPGP independente baseada em Rust (segurança de memória, design de biblioteca em primeiro lugar, participação ativa na IETF/ecossistema) onde muito do desenvolvimento público acontece. Não é este projeto; está documentado aqui como um caminho alternativo prático quando o upstream aqui está 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 recursos comerciais maiores podem exigir acordo prévio e arranjos de manutenção de 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 aplicativos relevantes não serão compilados para macOS ou Windows. As ferramentas de host (galdra, galdrad, galdra-gtk) e o ferramental de suporte 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; isso nunca foi totalmente comprovado 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 gerenciadores de pacotes são geralmente seguros, mas instalações de terceiros .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 toolchain Rust estável conforme fixada em rust-toolchain.toml. O firmware usa o alvo riscv32imac-unknown-none-elf; as ferramentas de host usam o triple do host.
test-hal vazar para builds de produção): ```bash
cargo run -p xtask -- check-fw
O código-objeto e os arquivos mortos ficam em target/riscv32imac-unknown-none-elf/release/. Uma imagem completa e inicializável do sistema Xous para uma placa específica é produzida pelo fluxo de integração mais amplo do Baochip / Xous quando você segue o build desse produto; xtask aqui executa cargo build para os crates da biblioteca de firmware listados em xtask (não um único arquivo pronto para gravação por si só).
Daemon Xous CCID (galdralag-service) — requer o toolchain Xous riscv32imac-unknown-xous-elf (não o triple de firmware bare riscv32imac-unknown-none-elf acima).
Árvore xous-core necessária: as dependências de caminho são resolvidas por meio de Galdralag-firmware/xous-core/. Os builds de imagem devem usar um checkout irmão (ou XOUS_CORE=) no branch feature/usb-bao1x-ccid-openpgp (PR #937). Árvores aninhadas e irmãs podem divergir; cargo run -p xtask -- check-xous-core falha
com código não zero e imprime um ln -sfn <sibling> ./xous-core copiável (renomeie um
checkout aninhado real primeiro se ./xous-core ainda não for um symlink): ```bash
ln -sfn ../xous-core ./xous-core
cargo run -p xtask -- check-xous-core
Imagem Dabao CCID que inclui Galdralag (apenas dabao-ccid sozinho é somente transporte): ```bash
scripts/build_dabao_ccid_image.sh
**BaoSec + PDDB:** **`cargo run -p xtask -- build-and-register release --xous-core /path/to/xous-core`**. Detalhes: [services/galdralag/README.md](https://github.com/supermagnum/galdralag-firmware/blob/main/services/galdralag/README.md). Lacunas exclusivas do upstream: [docs/XOUS_CORE_UPSTREAM_REQUESTS.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/XOUS_CORE_UPSTREAM_REQUESTS.md).
### Gravação (Flashing)
Este repositório **não** inclui ainda um gravador de comando único. A programação do **Baochip-1x** (JTAG, boot ROM/USB ou ferramentas do fornecedor) segue a documentação da placa e do silício. Comece por **[Supermagnum/Baochip-1x-firmware](https://github.com/Supermagnum/Baochip-1x-firmware)**; o **hardware da placa de avaliação** está em **[baochip/dabao](https://github.com/baochip/dabao)** — na placa Dabao, o **SW2** alterna o **modo bootloader** (ver esse esquema).
**Gravar UF2 sem o botão físico de boot:** Após copiar **`loader.uf2`**, **`xous.uf2`** e **`apps.uf2`** para o volume **BAOCHIP**, pode premir o botão físico **boot** **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 para este passo. O console **desliga** quando digita **`boot`**; isso é **esperado** (o sistema reinicia para a próxima fase). No Linux, `dmesg --follow` ajuda a confirmar a reenumeração USB. Isto é distinto do **PROG** (manter premido ao ligar USB para entrar no bootloader de armazenamento em massa **BAOCHIP**). Ver **[baochip/dabao#2](https://github.com/baochip/dabao/issues/2)** (fechado).
**Fluxo Xous / Baochip:** As imagens são **assinadas com Ed25519** e verificadas pelo **boot0** antes da execução; ver [Firmware assinado (Ed25519, boot0)](#signed-firmware-ed25519-boot0). Para **dabao**, o layout **UF2**, manter **PROG** premido ao ligar USB para entrar no modo de armazenamento em massa e os passos de atualização do **boot1**, ver **[Getting Started with Baochip Targets](https://github.com/betrusted-io/xous-core/blob/dev/README-baochip.md)**.
### Compilar e instalar ferramentas do host (`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
# required only for `galdra-gtk`:
sudo apt install libgtk-4-dev
libpcsclite-dev satisfaz o caminho de ligação PC/SC padrão do galdra; pcscd é o daemon que atende leitores de cartões inteligentes em tempo de execução. libssl-dev é necessário para que openssl-sys possa fazer a ligação (as consultas de keyserver do sequoia-net e o TLS do ldap3 usam native-tls atualmente). Omita libgtk-4-dev se você nunca compilar galdra-gtk.
GTK 4 (somente galdra-gtk): o 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
Executables: `target/release/galdra`, `target/release/galdrad`, `target/release/galdra-gtk`.
**Instalação** 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
Em vez disso, pode copiar esses três binários para qualquer diretório no seu PATH.
galdrad e a GUI de ambiente de trabalho (galdra-gtk)galdra-gtk é o binário de ambiente de trabalho GTK4 (pacote Cargo galdra-gtk; não existe galdra-gui). É uma interface para a API REST galdrad — execute o galdrad primeiro.
Daemon — o galdrad escuta em 127.0.0.1:8742 por predefinição (--listen substitui); consulte galdrad/src/main.rs.```bash
galdrad
Verifica rápida: `curl -s http://127.0.0.1:8742/health` (documentação interativa da API: **`http://127.0.0.1:8742/swagger-ui/`**.)
**GUI para desktop** — **`galdra-gtk`** usa **`http://127.0.0.1:8742`** por padrão (`--base-url` ou **`GALDRAD_URL`**); consulte [`galdra-gtk/src/main.rs`](https://github.com/supermagnum/galdralag-firmware/blob/main/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
A partir de um cargo build --release limpo, sem instalar: ./target/release/galdrad e depois ./target/release/galdra-gtk a partir da raiz do repositório.
Host vs token: galdra-gtk espelha o que galdrad expõe via HTTP; o unlock de token, provision e outros fluxos CCID permanecem na CLI galdra (consulte galdra device em docs/GALDRA-TOOL.md e o Nível 2c).
Diretório de contactos (galdra contact, galdrad /contacts): criar um contacto exige um e-mail (CLI: --email; HTTP: campo JSON email). Os campos opcionais incluem nome de exibição (--name / name), organização (--org / org), função, crachá (--badge / badge), nota, indicativo, Fluxer, Discord e IDs de IRC, número de telefone (--phone-number / phone_number), além de (, , , ), de rádio-amador e . Esses valores são armazenados apenas nos metadados locais do SQLite (não são em serviços externos). um contacto (por exemplo, , caminhos /, do , IDs de membros de grupo ou em ) aceita o da linha, , , uma completa (espaços ignorados), esses IDs sociais ou um em quando fornecido como token decimal. pode espelhar muitos dos mesmos rótulos num registo estilo Fulla (, , , , , campos de rádio/social/postal e nomes — consulte ). Os comandos e limites de campos estão resumidos em em e .
Se usou cargo install --path como acima:```bash
cargo uninstall galdra
cargo uninstall galdrad
cargo uninstall galdra-gtk
Se copiou binários manualmente, remova os arquivos que você adicionou. O firmware não é "instalado" no host; apagar ou regravar o dispositivo é coberto pela documentação do seu hardware.
---
## Principais capacidades
### O que torna este token incomum
Os itens abaixo são **capacidades do firmware Galdralag**, não requisitos do [aplicativo de cartão OpenPGP](#padrões-vs-recursos-específicos-do-firmware) 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 hoje; um terceiro fator **biométrico** opcional **não** está implementado neste repositório (placeholder: [docs/BIOMETRIC_API.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/BIOMETRIC_API.md)). Consulte [docs/THREE_FACTOR_AUTH.md](https://github.com/supermagnum/galdralag-firmware/blob/main/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. Até onde os autores do projeto sabem, nenhum token de segurança de hardware comercial oferece 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 reconstrução, sem que nenhum detentor individual consiga recuperar a chave sozinho. Até onde os autores do projeto sabem, nenhum token comercial oferece isso como um recurso de primeira classe também. **Controle duplo** (dois tokens necessários antes que uma porta abra ou um volume seja montado) **não** é aplicado aqui; consulte [Quórum de chave dupla de hardware (padrão de integrador)](#quórum-de-chave-dupla-de-hardware-padrão-de-integrador).
- **Sistema de perfil agnóstico de cifra** — 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** AEADs simétricos **diferentes** 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 **independente** derivado de HKDF por camada. Nomes integrados como `standard`, `conservative` e `conservative-shamir` vêm com **uma ou duas** camadas; pilhas mais profundas são para perfis avançados ou personalizados. Regras completas e layout de fio: [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md). Cada seleção de perfil é registrada na trilha de auditoria.
- **BLAKE3 com chave entre camadas em cascata (CESS)** — Além da tag AEAD de cada camada e do envelope externo ChaCha20-Poly1305 do **Modo A**, o **CESS** define integridade estilo **BLAKE3 com chave** **entre** estágios internos da cascata. Para perfis **mapeados por registro** (`suite_id` via nomes integrados), **`cipher-profile`** anexa um **HMAC-BLAKE3 de 32 bytes** sobre a saída AEAD de cada camada interna antes que a próxima camada criptografe; as chaves são derivadas com **HKDF-BLAKE3** usando `cess::cess_blake3_integrity_gap_info` ([`inner_info.rs`](https://github.com/supermagnum/galdralag-firmware/blob/main/crates/cess/src/inner_info.rs)). Integrados de **camada única** pulam tags extras; perfis **personalizados** (sem `suite_id`) mantêm a cascata legada sem MACs entre camadas. Consulte [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md) e [docs/CESS_CONFORMANCE.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CESS_CONFORMANCE.md). **Contagens de combinações** sob as regras de cifra `cipher-profile` (**cinco** primitivas AEAD, **nenhuma cifra repetida** em um perfil, a ordem importa); a coluna BLAKE3 é a contagem do **espaço de design** do CESS (ligado/desligado independente por lacuna), não um alternador de host por mensagem:
| Comprimento da cascata | Pilhas ordenadas de cifras distintas | × BLAKE3 opcional ligado/desligado 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** |
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** é o mesmo número de pilhas multiplicado por cada padrão **independente** ligado/desligado 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 integrado com **`suite_id`** tem **≥ 2** camadas (não um alternador por lacuna). Os nomes de perfil integrados usam um subconjunto **pequeno** dos 205.
- **Volume isca microSD opcional** — se um chip PSRAM estiver instalado, um LUN de massa extra de isca pode aparecer após o desbloqueio. **Se nenhum microSD estiver instalado, 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 em massa opcional está ausente. Para hosts não informados, o dispositivo ainda apresenta a persona usual de armazenamento em massa no chip onde configurado. O conteúdo do microSD, quando presente, é intencionalmente não criptografado e sem destaque. O material de chave real vive na RRAM no chip atrás do cofre e da política de PIN.
- **Pilha totalmente aberta** — RTL CERN-OHL-W-2.0, esquemáticos abertos, bootloader reproduzível, SO Rust/Xous, silício inspecionável por IRIS.
### Quórum de chave dupla de hardware (padrão de integrador)
**O que é:** Uma maneira de organizações exigirem **dois (ou K-de-N) tokens físicos separados ou detentores de partes** antes que um **sistema downstream** desbloqueie algo crítico — discos criptografados, sessões de administração de **firewall ou servidor**, **cofres de medicamentos**, portas seguras ou outras ações privilegiadas.
**O que o Galdralag fornece:** Cada token é **uma credencial independente**: autenticação de cartão OpenPGP (token + PIN) e, via ferramentas de host, **exportação de parte Shamir** do material de chave de longo prazo ([`vault::shamir`](https://github.com/supermagnum/galdralag-firmware/blob/main/crates/vault/src/shamir.rs), [`galdra shamir`](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md)). **Identidades públicas estáveis** (impressões digitais OpenPGP, seriais de token) suportam registros de auditoria de **qual chave foi usada, quando**.
**O que o Galdralag não fornece:** O firmware e as ferramentas de host **não bloqueiam** assinatura, descriptografia ou desbloqueio até que dois tokens estejam presentes juntos. **Aplicação de quórum**, janelas de tempo de sessão, ambiente seguro de reconstrução e **logs de acesso** à prova de violação são responsabilidade do **integrador** — daemon de desbloqueio LUKS, gerenciamento de acesso privilegiado (PAM), software de porta/painel ou gateway de política personalizado.
**Padrão típico:** Divida um segredo mestre de desbloqueio **2-de-3** (ou similar); o custodiante A detém a parte 1 no token A, o custodiante B detém a parte 2 no token B; no momento do desbloqueio, o gateway coleta **K** partes ou **K** assinaturas de token, reconstrói ou autoriza **uma vez**, então zera o segredo. Alternativa: duas operações **SIGN** OpenPGP em um desafio dentro de uma janela de tempo, sem reconstrução Shamir.
Este é um **padrão de extensão suportado** usando primitivas existentes — **não** um recurso de produto enviado e **não** um compromisso de roadmap. Design, limites de responsabilidade, notas de segurança e registro de responsabilização: [docs/DUAL_KEY_QUORUM.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/DUAL_KEY_QUORUM.md). Consulte também [Compartilhamento de segredo Shamir e criptografia de unidade](#compartilhamento-de-segredo-shamir-e-criptografia-de-unidade) e [docs/AUDIT_LOG.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/AUDIT_LOG.md).
### Capacidades criptográficas
Todas as primitivas vêm de dependências de workspace auditadas independentemente. Nada é implementado no repositório.
#### Assimétrico / acordo de chaves
| 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 assinar / verificar | RFC 8032 | |
| RSA-2048 / 3072 / 4096 OAEP, PSS, PKCS#1 v1.5 assinar/verificar | RFC 8017 | Somente biblioteca `galdr-vault` (mínimo de 2048 bits). Criptografar/descriptografar OAEP-SHA256; assinar/verificar PSS SHA-256/SHA-512; assinar/verificar PKCS#1 v1.5 atrás de um marcador `Pkcs1v15` no código-fonte (somente interoperabilidade legada, não para novos designs de protocolo). **Não** acessível através do aplicativo de cartão OpenPGP — SIG/DEC/AUT não operam RSA; consulte [docs/OPENPGP_CARD.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/OPENPGP_CARD.md). |
| P-256, P-384 | NIST | Via deps de workspace `p256` / `p384` |
#### Simétrico / AEAD
| Algoritmo | Padrão | Notas |
|-----------|----------|-------|
| AES-256-GCM | FIPS 197, NIST SP 800-38D | AES de 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 |
#### Derivação de chave / MAC / digest
| 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 |
| Família SHA-3 | FIPS 202 |
| BLAKE2b / BLAKE2s | RFC 7693 |
| BLAKE3 | Especificação BLAKE3 |
#### Gerenciamento de chaves
| 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 (por exemplo, **três** camadas independentes); chaves por camada — `cipher-profile` — [docs/CIPHER_PROFILES.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/CIPHER_PROFILES.md) |
### Propriedades de segurança
| Propriedade | Implementação |
|----------|---------------|
| Sigilo de encaminhamento | ECDH efêmero: a chave de longo prazo apenas assina, nunca concorda |
| Contador de PIN antes da comparação | Contador gravado na RRAM antes de `subtle::ConstantTimeEq` — sem exceções |
| Zeroização de hardware | Sobrescrita multi-passagem originada de TRNG; boot0 zera antes da enumeração USB |
| Nenhum segredo no barramento USB | Host não informado 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 ativo |
| 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](https://github.com/supermagnum/galdralag-firmware/blob/main/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 em RAM — log de auditoria NV somente anexação **não** implementado — [docs/AUDIT_LOG.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/AUDIT_LOG.md), [docs/RRAM_LAYOUT.md](https://github.com/supermagnum/galdralag-firmware/blob/main/docs/RRAM_LAYOUT.md) |
| Operações em tempo constante | Todas as comparações de segredos via `subtle`; verificado por harnesses dudect |
| test-hal nunca em produção | Aplicado por `check-fw` (firmware) e `check-host` (binários de host de release) |
### Política de PIN
- Comprimento mínimo: **5 caracteres alfanuméricos** — aplicado no limite do parser, antes que `pin-policy` seja chamado. Entradas curtas não incrementam o contador.
- Limite padrão de tentativas: **3** (configurável **3–10** no provisionamento). Corresponde ao padrão da indústria de tokens de hardware (Nitrokey, YubiKey, ISO 7816).
- Ao atingir o limite: zeroização completa de hardware acionada.
- Frase secreta de desafio/resposta (caminho de host informado via USB): mínimo de 5 caracteres, transmitida apenas como `HMAC-SHA256(HostChallengeKey, nonce || passphrase)`.
**Definir ou ajustar o limite de tentativas:** O limite do contador é gravado quando o token é **provisionado pela primeira vez**; **não** é uma configuração de `gpg` em tempo de execução. Use a ferramenta de host **`galdra`** após [compilá-la](#compilar-e-instalar-ferramentas-de-host-galdra-galdrad-galdra-gtk):```bash
galdra device provision --pin-attempts 5
| Flag | Intervalo | Padrão | Significado |
|---|---|---|---|
--pin-attempts |
Omita ambas as flags 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 do host não pode aumentar ou diminuir o limite após o provisionamento sem passar pelo fluxo de gerenciamento autenticado do próprio dispositivo; trate o provisionamento como o momento de escolher 3–10 para o seu modelo de ameaça. A justificativa (padrões vs. limites mais altos) está detalhada em docs/GALDRA-TOOL.md na seção de política de PIN.
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. Os crates Rust subjacentes
não foram auditados de forma independente. Consulte
docs/PQ_SIGNATURES.md e
docs/STATEFUL_SIG_STATE.md.
Estes algoritmos são padronizados pelo NIST. A implementação está bloqueada até que um
crate Rust no_std auditado de forma independente esteja disponível.
| Campo | Finalidade | Anfitrião (galdra SQLite) | Armazenamento de contactos no chip | Formato / limite |
|---|
| ID de contacto | Chave primária estável do anfitrião | Sim | Não | Texto (id em SQLite) |
| Nome de exibição | Etiqueta legível por humanos | Sim | Sim | String UTF-8; máx. 240 bytes por campo de heap no chip |
| Endereço de correio principal | Sim | Sim | String UTF-8; pesquisa no chip por digitalização de e-mail | |
| Indicativo | Indicativo de rádio amador | Sim | Sim | 12 bytes, preenchido com NUL; pesquisa no chip |
| ID de assinante DMR | ID de rádio DMR | Sim | Sim | 32 bits sem sinal (0 = ausente); pesquisa no chip |
| Número de crachá | ID de funcionário ou crachá | 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 | Etiqueta de cargo ou função | Sim | Sim | String UTF-8 |
| Nota | Comentário de forma livre | Sim | Sim | String UTF-8 |
| Afiliação de rádio | Etiqueta de clube, rede ou aliança | Sim | Sim | String UTF-8 |
| Rua | Linha de endereço de rua | Sim | Sim | String UTF-8 |
| País | Nome ou código de 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 | Identificador ou handle 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 de voz ou SMS | Sim | Não | String UTF-8; máx. 32 caracteres no anfitrião; declarado pelo remetente, 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 chaves) | Algoritmo: Ed25519, X25519, Brainpool P-256/P-384/P-512, NIST P-256/P-384, RSA-2048/3072/4096; blob de até 768 bytes no chip |
| Chave protegida por PIN | Chave requer desbloqueio por PIN | O anfitrião armazena chaves OpenPGP separadamente | Sim | Digest do verificador de PIN + metadados de encapsulamento AES-GCM no chip |
| Última obtenção | Quando o material de chave foi atualizado | Sim (fetched_at) | Sim (last_fetched) | UTC no anfitrião; carimbo de tempo de 32 bits no chip |
| Expira em | Tempo de expiração da chave | Sim | Não | Data/hora UTC apenas em SQLite |
| Fonte da chave | Como o registo do anfitrião foi criado | Sim (source) | Não | ex.: manual, keyserver, WKD, LDAP, ficheiro, peer |
| Proveniência do campo | Etiqueta de confiança por campo de metadados | Não | Sim (source_map) | Dois bits por campo: SelfAttested, HostVerified, RegistrySync, OobVerified |
| Sinalizadores de registo | Ativo, obsoleto, identidade própria, revogado | Parcialmente (lógica do anfitrião) | Sim | ex.: STALE, SELF_KEY no chip |
fuzz/README.mdtest-all --no-dudect: Omite a suíte de temporização dudect (~15–20 minutos). O CI de pull-request utiliza este sinalizador. Execute cargo run -p xtask -- timing-test ou test-all sem --no-dudect para o portão de temporização. O CI semanal (test-all-full) ainda executa dudect.docs/TEST_RESULTS.md para o que está no âmbito.| Campo de metadados | OpenPGP / GnuPG | Chave Galdra (host + armazenamento de contatos) |
|---|
| ID de contato / registro | Não (use ID de chave ou impressão digital) | Sim (id SQLite no host; não no chip) |
| Nome de exibição | Apenas dentro do texto User ID (Nome <email>) | Sim (campo UTF-8 separado) |
| Apenas dentro do texto User ID | Sim (campo separado; busca por e-mail no chip) | |
| Endereço | Sem campo padrão | Sim |
| País | Sem campo padrão | Sim |
| CEP / código postal | Sem campo padrão | Sim |
| Região / estado | Sem campo padrão | Sim |
| Organização | Sem campo padrão | Sim |
| Departamento | Sem campo padrão | Sim |
| Função / cargo | Sem campo padrão | Sim |
| ID de crachá / funcionário | Sem campo padrão | Sim |
| Indicativo (callsign) | Sem campo padrão | Sim (12 bytes, preenchido com NUL no chip) |
| ID de assinante DMR | Sem campo padrão | Sim (32 bits; busca no chip) |
| Afiliação de rádio | Sem campo padrão | Sim |
| ID Fluxer | Sem campo padrão | Sim |
| ID Discord | Sem campo padrão | Sim |
| ID IRC | Sem campo padrão | Sim |
| Número de telefone | Sem campo padrão | Sim (apenas SQLite do host) |
| Nota de forma livre | Sem 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 em SQLite) |
| Hora da última busca de chave | Dependente da ferramenta do host | Sim (fetched_at / last_fetched) |
| Chave privada no token | Slots de cartão SIG, DEC, AUT | Região de chave Galdra separada (sem pacotes User ID) |
| PIN para usar chave privada | PW1 / PW3 (cartão OpenPGP) | Envoltório PIN opcional por registro de contato Galdra |
| Objeto de cartão OpenPGP (não na tabela acima) | Host (GnuPG) | No token |
|---|
| Subchaves primária + SIG / DEC / AUT | Pública no keyring | 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 |
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 de host que outros smart cards OpenPGP (gpg, scdaemon, CCID) |
| USB CCID — comunicar-se 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 isso; 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) |
| Chave dupla de hardware / autorização por quórum — dois (ou N) tokens exigidos antes que um consumidor aja (desbloqueio de disco, liberação de porta, operações privilegiadas) | Não na especificação do cartão OpenPGP | Não — padrão de extensão suportado para integradores que usam Shamir e/ou múltiplas autenticações OpenPGP; a aplicação pertence ao sistema downstream (docs/DUAL_KEY_QUORUM.md) |
| 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 de 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 de host |
| Isca microSD / personas de armazenamento em massa — comportamento USB para hosts desinformados | Não na especificação do cartão OpenPGP | Não — caminhos de código separados de personalidade USB |
| WebAuthn / FIDO2 | CTAP / WebAuthn | Não implementado — padrão diferente do cartão OpenPGP |
| Camada | Papel |
|---|
| Disco | Criptografado com uma chave mestra (ex.: AES-256 via LUKS, VeraCrypt ou uma camada de bloco bruto) |
| Chave mestra | Dividida com SSS em N partes, limite K-de-N |
| Partes | Guardadas por pessoas, dispositivos ou armazenamento offline; K partes juntas reconstroem a chave mestra |
| Desbloqueio | Reconstruir a chave e passá-la para cryptsetup, veracrypt ou sua pilha |
| Limiar | 2-de-3 (equipe pequena, alguma redundância); 3-de-5 (comum em organizações) |
| Armazenamento das partes | Tokens de hardware, máquinas separadas, papel, sites geograficamente divididos |
| Proteção das partes | Criptografar cada parte para um destinatário específico (ex.: com a chave OpenPGP dele) antes da distribuição |
| Onde reconstruir | Máquina isolada (air-gapped), política de HSM ou ambiente controlado — não em hosts compartilhados não confiáveis |
| Cenário | Por que SSS mais curvas fortes e alinhadas a políticas importam |
|---|
| Funcionário sai ou morre | A recuperação permanece possível sem o segredo exclusivo dessa pessoa |
| Acesso legal sob devido processo | Um quórum pode ser exigido — nenhuma parte única detém o segredo completo de desbloqueio |
| Caução corporativa de chaves | Divisão auditável; nenhum administrador único 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ães e da UE |
| Assinatura do Governikus | Confirma que o nome no certificado correspondeu à identidade autenticada por chip quando o usuário concluiu o fluxo |
| Jurisdição | Status abordado neste documento |
|---|
| Alemanha | Fluxo Governikus/BSI descrito acima |
| Estônia | eID baseado em chip. Migrou de RSA para ECDSA NIST P-384 (secp384r1) 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 é vinculada ao hardware e não pode ser lida do cartão. Nenhum serviço de assinatura OpenPGP estilo Governikus conhecido encontrado. |
| Bélgica | eID baseado em chip. Cartões mais antigos usavam RSA de 1024 bits; cartões mais novos (applet 1.8 em diante) usam ECDSA NIST P-384. Ecossistema ativo de middleware de código aberto (eid-mw, OpenSC). Nenhum serviço de assinatura OpenPGP estilo Governikus conhecido encontrado. |
| Noruega | O chip do cartão de identidade nacional (emitido desde 2020) é compatível com ICAO 9303 e implementa apenas um chip de documento de viagem; ele não carrega função de assinatura eID. A assinatura eID é separada: provedores privados credenciados (Buypass, Commfides) sob SEID, historicamente RSA de 2048 bits, migrando para RSA de 3072 bits com ECC introduzido no SEID 2.0. Nenhum serviço de assinatura OpenPGP estilo Governikus conhecido. O chip de viagem e o 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); curva específica não confirmada nas fontes disponíveis. Modelo de Bürgerkarte com múltiplos tokens em vez de um único cartão; amplamente migrado para um aplicativo móvel. Investigação adicional necessária sobre detalhes da curva e qualquer serviço de assinatura OpenPGP. |
| EUA | Cartão PIV (Verificação de Identidade Pessoal, FIPS 201 / NIST SP 800-78): emitido apenas para funcionários e contratados 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/gerenciamento de chaves; RSA 2048/3072 também permitido; apenas curvas NIST, sem Brainpool. A raiz de confiança é a Autoridade de Certificação de Política Comum Federal (FCPCAG2), não incluída nos armazenamentos de confiança comerciais padrão. Nenhum serviço de assinatura OpenPGP estilo Governikus encontrado; FPKI é uma infraestrutura X.509 separada do OpenPGP. 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 identidade nacional baseado em chip com chaves de assinatura no chip. A identidade digital é fragmentada em esquemas provinciais (por exemplo, BC Services Card), aplicativos móveis (por exemplo, eID-Me) e uma estrutura federal em evolução de credenciais digitais. Nenhum cartão único comparável ao modelo alemão, estoniano ou belga. Nenhuma infraestrutura de cartão equivalente encontrada — não é uma âncora de confiança viável nesse sentido. |
| Outros países | Não investigado |
| Objetivo | Por onde começar |
|---|
| Visão geral do projeto, notícias, comunidade | sequoia-pgp.org |
| Contribuir (issues, correções, recursos, documentação); contatar antes de trabalho grande | Contribute, Contact |
Docs de desenvolvedor — superfície de API para estender a implementação (sequoia-openpgp e crates relacionados) | 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 OpenPGP da IETF. Sequoia e outras implementações implementam rascunhos e RFCs; proponha mudanças de protocolo lá e coordene com implementadores (incluindo Sequoia) para que o comportamento corresponda à especificação. |
streetcountrypostal_coderegiondmr_idradio_affiliationgaldra contact showPATCHDELETEGET /contacts/{id}galdradrecipientPOST /decryptgaldra keyserver pushorganisationrolenotebadge_numberphone_numbergaldra keyserver push --help| 3–10 |
| 3 |
| Tentativas de PIN falhas permitidas antes do bloqueio / zeragem |
--min-pin-length | 5–32 | 5 | Comprimento mínimo do PIN do usuário (alfanumérico) armazenado na política |
| Algoritmo | Padrão | Aguardando |
|---|
| ML-KEM | FIPS 203 | Crate Rust no_std auditado |
| ML-DSA | FIPS 204 | Crate Rust no_std auditado |
| SLH-DSA | FIPS 205 | Crate Rust no_std auditado |