Vouchers com assinatura cega e credenciais anônimas de acesso

AeroNyx usa assinatura cega em dois caminhos de autorização distintos. Ambos reduzem correlação de identidade, mas rollout e replay guarantees diferem. Esta página descreve Rust main, recursos controlados pelo deployment e inferências proibidas.

Dois caminhos de credenciais

VPN autoriza ClientHello com credential blind-signature finalizada. Blind Vault V2 cria lease aleatório autoautenticado via RFC 9474. V1 é bearer one-time de compatibilidade, correlacionável, não blind issuance.

Invariante de privacidade

O objetivo é autorizar sem entregar issuance identity ao node. Signer, entitlement backend, storage node e console são boundaries separados; juntar records por request destrói unlinkability.

• Node valida direitos sem wallet/account identity.
• Signer recebe blinded bytes e key ID, não entitlement identity.
• Secrets, tokens, randomizers, spend/lease IDs e private keys não são logados.
• Counters agregados não são unidos a per-user traffic.
• Não é blind signing de wallet para aprovar transaction desconhecida.

Voucher do handshake VPN

O client envia extensão AVCH limitada. Rust parseia apenas campos, busca chave por epoch, cacheia por uma hora e verifica RSA-PSS SHA-384 randomized sem wallet/account ID.

ClientHello fixed frame
  + magic: AVCH
  + voucher_length: u16 little-endian
  + voucher JSON (maximum 2048 bytes)

{
  "token": "base64-final-credential-message",
  "signature": "base64-finalized-blind-signature",
  "msg_randomizer": "base64-32-byte-randomizer",
  "epoch": "issuer-key-epoch"
}

O fluxo só é blind se o client cega antes da assinatura. Assinar token ligado à identidade não é equivalente. Token, signature, randomizer e epoch são bearer secrets e não entram em logs.

Limite atual do rollout VPN

VPN está em reject_invalid: malformed/invalid são rejeitados, missing ainda é aceito para migração. Não é mandatory enforcement.

mode = reject_invalid
valid | invalid | missing | malformed | total
valid_ratio | invalid_ratio | missing_ratio | malformed_ratio
last_observation | last_error

VoucherVerifier verifica e agrega resultados, mas não gasta token em tabela atômica. Não há node one-time redemption; sharing, replay, quota e expiry precisam de contrato versionado.

Admissão Blind Vault V2

Blind Vault V2 descobre epochs assinados, cega mensagem RFC 9474, recebe assinatura do issuer isolado, finaliza local e chama /api/vault/v1/lease. API e pinned issuers precisam estar ativos.

GET  /api/vault/v1/issuers
POST /api/vault/v1/lease
POST /api/vault/v1/put
POST /api/vault/v1/pull
POST /api/vault/v1/delete
Content-Type: application/vnd.aeronyx.blind-vault-v1

client blinds RFC 9474 admission message
  -> entitlement backend authorizes issuance
  -> isolated blind issuer signs blinded bytes only
  -> client finalizes signature
  -> node verifies active public epoch
  -> atomic spend marker + random self-authenticating lease
  -> ciphertext storage operations use lease-scoped keys/capabilities

Isolamento do issuer e rotação

A operação privada vive em aeronyx-blind-issuer, recebendo version, fingerprint e bytes RSA cegos. Não possui account model, storage DB ou redemption visibility; interface serve software e futuro HSM/KMS.

Epochs incluem DER canônico, SHA-256 key ID, validade e max lease TTL. Updates exigem authority pinned separada, generation monotônica, continuity e persistence atômica; rollback falha fechado.

Spend atômico, idempotência e replay

V2 verifica credential e commita spend ID mais lease em transação SQLite imediata. Credential gasto não cria segundo lease; retry exato é idempotente.

V1/V2 compartilham spend table, mas schemes são separados: V1 raw ticket é linkable, V2 spend ID não. Isso pertence ao Blind Vault, não ao VPN verifier.

Observabilidade e Nodeboard

Nodeboard mostra somente validity, capacity, signer health e buckets agregados. last_observation/last_error não autorizam token, wallet, lease, request ou per-user dimension.

Evidência agregada permitida:

• totais/ratios VPN valid, invalid, missing, malformed
• counters issuer key, reload, capacity, rate, timeout, circuit
• saúde agregada Blind Vault de leases, objetos, bytes, expiry, cleanup
• mode, epochs, última observação e privacy boundary

Nunca expor:

• tokens, signatures, randomizers, blinded messages ou spend IDs
• wallet, account, payment, membership ou identidade social
• histórico per-user, lease/object/capability/request IDs
• IP client, destination, DNS, route, message ou browsing metadata
• private keys, provider errors, ciphertext, plaintext ou wallet traffic

Ameaças e limitações

Blind signature reduz linkage, não todos side channels. Timing, region, capacity, client compromise, issuer collection, theft, collusion e traffic correlation exigem relay cego, encryption, logs limitados e separation.

• correlação issuer collection e redemption timing
• theft, sharing, resale ou client compromise
• replay VPN antes de política versionada
• collusion issuer/backend/node/operator
• timing, region, capacity e traffic correlation
• rollback ou continuity quebrada
• telemetry agregada virando histórico per-user

Mapa do código

O código separa VPN verification, signing, wire contracts, Blind Vault admission/API/config e reporting. Essas boundaries devem permanecer.

Regras de desenvolvimento

Mudança termina quando crypto semantics, rollout, spend, observability, tests e idiomas concordam. Prefira claim estreito e verdadeiro.

1. Separar VPN e Blind Vault em nomes, código, telemetry e docs.
2. Não afirmar mandatory VPN enquanto missing é aceito.
3. Não afirmar one-time VPN sem atomic spend.
4. Manter signer sem account, wallet, lease, node ou redemption context.
5. Preservar continuity, fail-closed authority e atomicidade.
6. Somente aggregate health, nunca credential/identity dimensions.
7. Atualizar tests, Nodeboard e traduções com semântica.

Blind Vault: contatos criptografados e arquivo opcional