Bons à signature aveugle et justificatifs d'accès anonymes
Comment les bons VPN AeroNyx permettent à un nœud de vérifier le paiement sans connaître le compte payeur, ce que le déploiement reject_invalid autorise encore, ce que le nœud et le backend peuvent encore voir, et pourquoi l'admission Blind Vault est implémentée mais non déployée.
AeroNyx utilise des bons à signature aveugle afin qu'un nœud VPN puisse vérifier qu'une connexion est payée sans savoir quel compte a payé. Ce mécanisme est en service pour le VPN aujourd'hui, dans un mode de compatibilité qui accepte encore les connexions sans bon. Un second chemin de justificatif, l'admission Blind Vault, existe dans le logiciel de nœud, mais n'est pas déployé et n'est pas utilisé par l'application officielle.
Deux chemins de justificatifs
| Chemin de justificatif | État | Modèle d'échange |
|---|---|---|
| Bon de handshake VPN | En service. Fonctionne en mode de compatibilité reject_invalid | Le nœud vérifie la signature. Il ne suit pas les dépenses à usage unique |
| Admission Blind Vault V2 | Implémentée dans le nœud. Non déployée, et non utilisée par l'application officielle | Dépense à usage unique enregistrée de manière atomique avec la création du bail |
| Admission Blind Vault V1 | Compatibilité uniquement, dans le même composant désactivé | Dépense à usage unique, mais l'émission peut être reliée à l'échange |
Émission d'un bon VPN
- L'application génère un jeton aléatoire de 32 octets et l'aveugle localement, au moyen de signatures aveugles RSA (RSABSSA-SHA384-PSS-Randomized, RFC 9474).
- L'application n'envoie que le message aveuglé au backend AeroNyx, à
/api/voucher/issue/. Le backend vérifie que le compte connecté y a droit, signe le message aveuglé et renvoie la signature. Il ne voit jamais le jeton. - L'application finalise la signature localement. Le bon finalisé (jeton, signature, randomiseur de message et époque de clé) est un justificatif au porteur qui n'est pas relié à la requête d'émission.
Les clés publiques de l'émetteur, regroupées par époque, sont publiées à l'adresse :
GET https://api.aeronyx.network/api/voucher/issuer/keys/
Vérification d'un bon par un nœud
L'application ajoute une extension de bon au ClientHello 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"
}
Le nœud n'analyse que ces champs. Il récupère les clés publiques de l'émetteur pour l'époque auprès du point de terminaison ci-dessus, les met en cache pendant une heure et vérifie la signature RSA-PSS SHA-384 randomisée. Il n'a besoin d'aucun identifiant de portefeuille ni de compte.
Mode de déploiement : reject_invalid
- Les bons mal formés et cryptographiquement invalides sont rejetés avant que le handshake ne soit accepté.
- Une connexion sans aucun bon est toujours acceptée, afin que les clients plus anciens continuent de fonctionner. L'utilisation d'un bon n'est pas encore obligatoire.
- Le nœud n'enregistre pas les bons dépensés. Les nœuds acceptent un bon valide autant de fois qu'il est présenté, tant que l'époque de sa clé d'émetteur est encore publiée. Les limites de partage, de rejeu et de quota sont appliquées par le backend, et non par le nœud.
Les nœuds ne signalent que des résultats agrégés :
mode = reject_invalid
valid | invalid | missing | malformed | total
valid_ratio | invalid_ratio | missing_ratio | malformed_ratio
last_observation | last_error
Ce que le nœud apprend sur vous
La garantie selon laquelle « le nœud n'apprend jamais votre identité de portefeuille » ne vaut que pour les connexions avec bon.
- Connexions avec bon (l'application officielle) : l'application se connecte avec un bon et une clé de handshake temporaire et neuve. Le nœud peut vérifier le paiement, mais ne peut pas relier la session à votre portefeuille ni à votre identité P2P.
- Connexions héritées : un client qui s'authentifie avec sa clé d'identité au lieu d'un bon envoie cette clé lors du handshake.
Dans les deux cas, le nœud signale au backend AeroNyx la clé publique de handshake de la session dans un champ nommé client_wallet, accompagnée des heures de session et du nombre d'octets. Pour une connexion avec bon, cette valeur est la clé temporaire. Pour une connexion héritée, il s'agit de la clé d'identité du client. Les opérateurs de nœuds peuvent voir le trafic par session et ces clés dans Nodeboard.
Les bons ne masquent pas non plus tout le reste. Le nœud voit toujours votre adresse IP et, en tant que sortie, vos destinations et vos requêtes DNS, comme tout VPN. Lorsque l'application réserve une connexion quotidienne, le backend enregistre également que le compte s'est connecté à ce moment-là, mais pas quel nœud il a utilisé. Consultez la comparaison des VPN et le Centre de confiance.
Admission Blind Vault (non déployée)
Blind Vault est un composant de nœud destiné à stocker des objets chiffrés côté client sous des baux anonymes. Il est décrit dans MemChain et Blind Vault. Conception de son admission :
- V2 : le client aveugle un message d'admission RFC 9474. Un service de droits autorise l'émission, et un processus signataire distinct (
aeronyx-blind-issuer) ne signe que les octets aveuglés. Ce processus n'a ni base de données de comptes, ni stockage, ni visibilité sur les échanges. Le nœud vérifie le justificatif finalisé au regard d'une époque de clé publique épinglée et, dans une seule transaction SQLite, enregistre un marqueur de dépense et crée un bail aléatoire et auto-authentifiant. Un justificatif dépensé ne peut pas créer de second bail. Réessayer exactement la même requête renvoie le même bail. - V1 : un ticket au porteur avec la même table de dépenses à usage unique. Le nœud stocke l'identité du ticket : l'échange peut donc être relié à l'émission. Il n'est conservé que pour la compatibilité.
Le nœud n'expose ces routes que lorsque Blind Vault et son API publique sont tous deux activés. Les deux sont désactivés par défaut.
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
État actuel : Blind Vault n'est pas déployé sur les nœuds de production, l'application officielle n'appelle pas ces routes, et le backend AeroNyx ne dispose d'aucun point de terminaison de droits Blind Vault. Blind Vault n'est pas un produit de sauvegarde, d'archivage ni de stockage, et aucun produit de ce type n'est proposé.
Observabilité
Les interfaces destinées aux opérateurs n'affichent que l'état de santé agrégé des justificatifs :
- les totaux et ratios VPN
valid,invalid,missingetmalformed, ainsi que le mode de déploiement - la disponibilité des clés d'émetteur et des catégories approximatives d'échecs
Elles n'affichent jamais les jetons des bons, les signatures, les randomiseurs, les messages aveuglés ni les identifiants de dépense. Le trafic par session et les clés de handshake relèvent d'une vue opérateur distincte, décrite ci-dessus.
Modèle de menace et limites
Les signatures aveugles rompent le lien entre la requête d'émission et le bon. Elles n'éliminent pas les risques suivants :
- la corrélation temporelle entre les enregistrements d'émission ou de réservation de connexion du backend et les enregistrements de session d'un nœud, d'autant plus lorsqu'une même partie peut voir les deux
- le fait que le nœud voie votre adresse IP, vos destinations et vos requêtes DNS
- le vol, le partage ou la revente de bons tant que l'époque de leur clé est publiée, car les nœuds n'appliquent pas la dépense à usage unique
- les connexions sans bon, qui sont toujours acceptées en mode
reject_invalid - les erreurs de rotation des clés d'émetteur ou les clients compromis
Plan du code source
| Couche | Chemin dans le dépôt du nœud | Rôle |
|---|---|---|
| Vérificateur VPN | crates/aeronyx-server/src/voucher_verifier.rs | Analyse AVCH, récupère les clés par époque, vérifie les bons et enregistre les résultats agrégés |
| Signataire aveugle | crates/aeronyx-blind-issuer/src/signer.rs, api.rs | Signature aveugle RSA sans identité pour Blind Vault V2 |
| Contrats de format | crates/aeronyx-core/src/protocol/blind_vault.rs | Messages d'admission RFC 9474, époques de clés et identifiants de dépense |
| Service et API Blind Vault | crates/aeronyx-server/src/services/blind_vault.rs, api/blind_vault.rs | Admission, dépense et bail atomiques, routes d'objets |
| Configuration Blind Vault | crates/aeronyx-server/src/config_blind_vault.rs | Désactivé par défaut ; règles d'épinglage et de rotation des émetteurs |
Le logiciel de nœud est open source sous licence AGPL-3.0 sur github.com/AeroNyxNetwork/AeroNyx. L'application n'est pas open source.
<!-- faq:start -->Questions fréquentes
Un nœud VPN AeroNyx sait-il avec quel portefeuille j'ai payé ?
Pas pour les connexions avec bon, que l'application officielle utilise. Le nœud vérifie un bon à signature aveugle et une clé de handshake temporaire, dont aucun n'est relié à votre portefeuille. Un client hérité qui se connecte avec sa clé d'identité révèle en revanche cette clé au nœud.
Un bon peut-il être utilisé plusieurs fois ?
Oui. Les nœuds vérifient la signature au regard de la clé publiée pour l'époque du bon, mais ne tiennent pas de liste des bons dépensés. Les quotas sont appliqués par le backend.
Un bon est-il nécessaire pour se connecter ?
Pas encore. Les nœuds rejettent les bons mal formés ou invalides, mais acceptent toujours les connexions sans aucun bon, afin que les clients plus anciens continuent de fonctionner.
Où les clés d'émetteur des bons sont-elles publiées ?
Elles sont publiées à l'adresse https://api.aeronyx.network/api/voucher/issuer/keys/, regroupées par époque. Les nœuds mettent ces clés en cache pendant une heure.
Blind Vault est-il disponible dans l'application ?
Non. L'admission Blind Vault est implémentée dans le logiciel de nœud, mais elle est désactivée par défaut, n'est pas déployée et n'est pas utilisée par l'application officielle. AeroNyx ne propose aucun produit de sauvegarde ni de stockage.
<!-- faq:end -->