Vales de firma ciega y credenciales de acceso anónimo

AeroNyx usa vales de firma ciega para que un nodo VPN pueda comprobar que una conexión está pagada sin saber qué cuenta la pagó. Esto está activo hoy para la VPN, en un modo de compatibilidad que todavía acepta conexiones sin vale. Una segunda vía de credenciales, la admisión de Blind Vault, existe en el software de nodo, pero no está desplegada ni la usa la aplicación oficial.

Dos vías de credenciales

Cómo se emite un vale VPN

1. La aplicación genera un token aleatorio de 32 bytes y lo ciega localmente, usando firmas ciegas RSA (RSABSSA-SHA384-PSS-Randomized, RFC 9474).
2. La aplicación envía solo el mensaje cegado al backend de AeroNyx en /api/voucher/issue/. El backend comprueba que la cuenta con la sesión iniciada tiene derecho, firma el mensaje cegado y devuelve la firma. Nunca ve el token.
3. La aplicación finaliza la firma localmente. El vale terminado (token, firma, aleatorizador del mensaje y época de la clave) es una credencial al portador que no está vinculada con la solicitud de emisión.

Las claves públicas del emisor, agrupadas por época, se publican en:

GET https://api.aeronyx.network/api/voucher/issuer/keys/

Cómo comprueba un nodo un vale

La aplicación añade una extensión de vale al ClientHello de la VPN:

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

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

El nodo solo analiza estos campos. Obtiene las claves públicas del emisor para la época desde el endpoint anterior, las almacena en caché durante una hora y verifica la firma RSA-PSS aleatorizada con SHA-384. No necesita ningún identificador de billetera ni de cuenta.

Modo de despliegue: reject_invalid

• Los vales mal formados y los criptográficamente no válidos se rechazan antes de aceptar el handshake.
• Una conexión sin ningún vale se sigue aceptando, para que los clientes antiguos sigan funcionando. El uso de vales todavía no es obligatorio.
• El nodo no registra los vales gastados. Los nodos aceptan un vale válido tantas veces como se presente, mientras su época de clave del emisor siga publicada. Los límites de uso compartido, de repetición y de cuota los aplica el backend, no el nodo.

Los nodos solo notifican resultados agregados:

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

Qué sabe el nodo sobre usted

La garantía de que «el nodo nunca conoce su identidad de billetera» se cumple solo para las conexiones con vale.

• Conexiones con vale (la aplicación oficial): la aplicación se conecta con un vale y una clave de handshake nueva y temporal. El nodo puede verificar el pago, pero no puede vincular la sesión con su billetera ni con su identidad P2P.
• Conexiones heredadas: un cliente que se autentica con su clave de identidad en lugar de con un vale envía esa clave en el handshake.

En ambos casos, el nodo notifica al backend de AeroNyx la clave pública del handshake de la sesión en un campo llamado client_wallet, junto con las horas de la sesión y los recuentos de bytes. En una conexión con vale, ese valor es la clave temporal. En una conexión heredada, es la clave de identidad del cliente. Los operadores de nodos pueden ver en Nodeboard el tráfico por sesión y estas claves.

Los vales tampoco ocultan todo lo demás. El nodo sigue viendo su dirección IP y, como salida, sus destinos y su DNS, como cualquier VPN. Cuando la aplicación reserva una conexión diaria, el backend también registra que la cuenta se conectó en ese momento, pero no qué nodo usó. Consulte la comparación de VPN y el Centro de Confianza.

Admisión de Blind Vault (no desplegada)

Blind Vault es un componente del nodo para almacenar objetos cifrados por el cliente bajo concesiones anónimas. Se describe en MemChain y Blind Vault. Su diseño de admisión:

• V2: el cliente ciega un mensaje de admisión RFC 9474. Un servicio de derechos autoriza la emisión, y un proceso firmante independiente (aeronyx-blind-issuer) firma solo los bytes cegados. Ese proceso no tiene base de datos de cuentas, ni almacenamiento, ni visibilidad de los canjes. El nodo verifica la credencial finalizada con una época de clave pública fijada y, en una sola transacción SQLite, registra un marcador de gasto y crea una concesión aleatoria y autoautenticada. Una credencial gastada no puede crear una segunda concesión. Reintentar exactamente la misma solicitud devuelve la misma concesión.
• V1: un ticket al portador con la misma tabla de gasto de un solo uso. El nodo almacena la identidad del ticket, por lo que el canje puede vincularse con la emisión. Se mantiene solo por compatibilidad.

El nodo expone estas rutas solo cuando Blind Vault y su API pública están ambos habilitados. Ambos están desactivados de forma predeterminada.

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

Estado actual: Blind Vault no está desplegado en los nodos de producción, la aplicación oficial no llama a estas rutas y el backend de AeroNyx no tiene ningún endpoint de derechos de Blind Vault. Blind Vault no es un producto de copia de seguridad, archivo ni almacenamiento, y no se ofrece ninguno.

Observabilidad

Las superficies para operadores solo muestran el estado agregado de las credenciales:

• los totales y las proporciones de valid, invalid, missing y malformed de la VPN, y el modo de despliegue
• la disponibilidad de las claves del emisor y categorías aproximadas de fallos

Nunca muestran tokens de vales, firmas, aleatorizadores, mensajes cegados ni ID de gasto. El tráfico a nivel de sesión y las claves de handshake son una vista de operador aparte, descrita arriba.

Modelo de amenazas y límites

Las firmas ciegas rompen el vínculo entre la solicitud de emisión y el vale. No eliminan estos riesgos:

• la correlación temporal entre los registros de emisión o de reserva de conexiones del backend y los registros de sesión de un nodo, sobre todo cuando una misma parte puede ver ambos
• que el nodo vea su dirección IP, sus destinos y su DNS
• el robo, el uso compartido o la reventa de vales mientras su época de clave esté publicada, porque los nodos no imponen el gasto de un solo uso
• las conexiones sin vale, que todavía se aceptan en el modo reject_invalid
• los errores de rotación de las claves del emisor o los clientes comprometidos

Mapa del código fuente

El software de nodo es de código abierto bajo la AGPL-3.0 en github.com/AeroNyxNetwork/AeroNyx. La aplicación no es de código abierto.

Preguntas frecuentes

¿Sabe un nodo VPN de AeroNyx con qué billetera pagué?

No en las conexiones con vale, que son las que usa la aplicación oficial. El nodo verifica un vale de firma ciega y una clave de handshake temporal, y ninguno de los dos está vinculado con su billetera. Un cliente heredado que se conecta con su clave de identidad sí revela esa clave al nodo.

¿Se puede usar un vale más de una vez?

Sí. Los nodos verifican la firma con la clave publicada para la época del vale, pero no mantienen una lista de vales gastados. Las cuotas las aplica el backend.

¿Se necesita un vale para conectarse?

Todavía no. Los nodos rechazan los vales mal formados o no válidos, pero siguen aceptando conexiones sin ningún vale, para que los clientes antiguos sigan funcionando.

¿Dónde se publican las claves del emisor de vales?

Se publican en https://api.aeronyx.network/api/voucher/issuer/keys/, agrupadas por época. Los nodos almacenan estas claves en caché durante una hora.

¿Blind Vault está disponible en la aplicación?

No. La admisión de Blind Vault está implementada en el software de nodo, pero está deshabilitada de forma predeterminada, no está desplegada y no la usa la aplicación oficial. AeroNyx no ofrece ningún producto de copia de seguridad ni de almacenamiento.