Vales con firma ciega y credenciales anónimas de acceso

AeroNyx usa firma ciega en dos rutas de autorización distintas. Ambas reducen la vinculación de identidad, pero sus garantías de rollout y replay no son iguales. Esta página refleja Rust main, las capacidades controladas por despliegue y lo que nunca debe inferirse de una credencial.

Dos rutas de credenciales

VPN autoriza ClientHello con una credencial de firma ciega finalizada. Blind Vault V2 crea un lease aleatorio y autoautenticado con RFC 9474. V1 es compatibilidad bearer de un uso, vinculable, no emisión ciega.

Ruta	Estado actual	Modelo replay/redemption
VPN ClientHello voucher	Implementado; rollout compatible `reject_invalid`	Sin one-time spend en `VoucherVerifier`
Blind Vault V2 admission	Implementado en Rust; controlado por despliegue	Spend atómico e idempotent exact retry
Blind Vault V1 admission	Solo compatibilidad; V2 para nuevas integraciones	Spend atómico, pero emisión vinculable

Invariante de privacidad

El objetivo es autorizar sin entregar la identidad de emisión al nodo que redime. Signer, backend de entitlement, nodo de storage y consola deben ser límites separados; unir registros por request destruye la desvinculación.

El nodo valida derechos sin wallet/account identity.
El signer recibe blinded bytes y key ID, no identidad entitlement.
Secrets, tokens, randomizers, spend/lease IDs y private keys no entran en logs.
Counters agregados no se unen con tráfico por usuario.
No es el blind signing de wallets para aprobar transacciones desconocidas.

Voucher del handshake VPN

El cliente envía una extensión AVCH acotada. Rust analiza solo los campos, obtiene la clave pública por epoch, la cachea una hora y verifica RSA-PSS SHA-384 randomized. No necesita wallet ni account ID.

text

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

json

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

El flujo solo es ciego si el cliente blinda el mensaje antes de pedir firma. Una firma normal sobre un token ligado a identidad no equivale. Token, signature, randomizer y epoch son secretos bearer y no se registran.

Límite actual del rollout VPN

VPN está en modo compatible reject_invalid: malformed e invalid se rechazan antes del handshake; missing se acepta para retirar clientes antiguos. No es mandatory-voucher enforcement.

text

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

VoucherVerifier verifica y cuenta resultados agregados, pero no consume el token en una tabla atómica. No puede afirmarse one-time redemption del nodo; sharing, replay, quota y expiry requieren un contrato versionado.

Admisión Blind Vault V2

Blind Vault V2 descubre epochs firmados por el nodo, blinda el mensaje RFC 9474, obtiene firma del issuer aislado, finaliza localmente y usa /api/vault/v1/lease. Solo funciona donde public API e issuers pinned están activos.

http

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

text

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

Aislamiento del issuer y rotación

La operación privada vive en aeronyx-blind-issuer. Recibe version, fingerprint público y bytes RSA blindados; no posee accounts, storage DB ni visibilidad de redemption. Su interfaz admite software y futuros HSM/KMS.

Los epochs incluyen DER canónico, key ID SHA-256, validez y max lease TTL. Updates exigen autoridad pinned separada, generation monotónica, continuidad activa y persistencia atómica; rollback falla cerrado.

Spend atómico, idempotencia y replay

V2 verifica credential y confirma spend ID más lease en una transacción SQLite inmediata. Un credential gastado no crea otro lease; retry exacto del mismo lease es idempotente.

V1/V2 comparten tabla de spend pero separan schemes: V1 raw ticket es vinculable; V2 deriva spend ID desvinculado. Esta protección pertenece a Blind Vault, no a VPN VoucherVerifier.

Observabilidad y Nodeboard

Nodeboard solo muestra validity, capacity, signer health y buckets agregados. last_observation y last_error no permiten añadir token, wallet, lease, request o dimensión por usuario.

Evidencia agregada permitida:

Totales y ratios VPN valid, invalid, missing, malformed
contadores issuer de key, reload, capacity, rate, timeout y circuit
salud agregada Blind Vault de leases, objetos, bytes, expiry y cleanup
mode, epoch availability, última observación y privacy boundary

Nunca exponer:

tokens, signatures, randomizers, blinded messages o spend IDs
wallet, account, payment, membership o identidad social
historial por usuario, lease/object/capability/request IDs
IP cliente, destino, DNS, route, message o browsing metadata
private keys, provider errors, ciphertext, plaintext o wallet traffic

Amenazas y limitaciones

La firma ciega reduce linkage, no todos los side channels. Timing, region, capacity, client compromise, issuer collection, theft, collusion y traffic correlation requieren blind relay, cifrado, logs acotados y separación.

correlación de recogida issuer con redemption timing
theft, sharing, resale o client storage compromise
replay VPN antes de una política versionada
componentes issuer/backend/node/operator coludidos
timing, region, capacity y traffic correlation
rollback de keys o continuidad rota
telemetría agregada convertida en historial por usuario

Mapa del código

El código separa VPN verification, signing, wire contracts, Blind Vault admission/API/config y reporting. Esos ownership boundaries deben conservarse.

Capa	Ruta del repositorio	Función
VPN verifier	`crates/aeronyx-server/src/voucher_verifier.rs`	Analiza AVCH, descubre epochs, verifica voucher y cuenta rollout.
Blind signer	`crates/aeronyx-blind-issuer/src/signer.rs`	Política RSA identity-free y abstracción custody.
Issuer API	`crates/aeronyx-blind-issuer/src/api.rs`	Signing autenticado y acotado, epochs, pressure y health.
Wire contracts	`crates/aeronyx-core/src/protocol/blind_vault.rs`	Contratos RFC 9474, epochs, spend IDs, frames y firmas.
Blind Vault service	`crates/aeronyx-server/src/services/blind_vault.rs`	Admisión V1/V2 y commit atómico spend+lease.
Blind Vault API	`crates/aeronyx-server/src/api/blind_vault.rs`	Rutas issuers/lease/put/pull/delete y errores gruesos.
Blind Vault config	`crates/aeronyx-server/src/config_blind_vault.rs`	Pin de issuers/authority, TTL y rotación monotónica.
Health/reporting	`crates/aeronyx-server/src/api/vpn_health.rs` and `management/reporter.rs`	Estado agregado sin secrets ni wallet traffic.

Reglas de desarrollo

El cambio termina cuando crypto semantics, rollout, one-time spend, observability, tests y todos los idiomas coinciden. Es mejor una afirmación estrecha y verdadera que mezclar dos sistemas.

Separar semántica VPN y Blind Vault en nombres, código, telemetría y docs.
No afirmar mandatory VPN mientras missing se acepta.
No afirmar one-time VPN sin atomic spend.
Mantener signer libre de account, wallet, lease, node y redemption context.
Preservar continuidad, fail-closed authority y atomicidad.
Solo health agregado, nunca dimensión de credential o identity.
Actualizar tests, Nodeboard y traducciones al cambiar semántica.

Blind Vault: contactos cifrados y archivo opcional