Vouchers de assinatura cega e credenciais de acesso anônimas

A AeroNyx usa vouchers de assinatura cega para que um nó de VPN possa verificar que uma conexão foi paga sem descobrir qual conta pagou. Isso está em funcionamento na VPN hoje, em um modo de compatibilidade que ainda aceita conexões sem voucher. Um segundo caminho de credenciais, a admissão do Blind Vault, existe no software de nó, mas não está implantado nem é usado pelo aplicativo oficial.

Dois caminhos de credenciais

Como um voucher de VPN é emitido

1. O aplicativo gera um token aleatório de 32 bytes e o cega localmente, usando assinaturas cegas RSA (RSABSSA-SHA384-PSS-Randomized, RFC 9474).
2. O aplicativo envia apenas a mensagem cegada ao backend da AeroNyx em /api/voucher/issue/. O backend verifica se a conta conectada tem direito, assina a mensagem cegada e retorna a assinatura. Ele nunca vê o token.
3. O aplicativo finaliza a assinatura localmente. O voucher pronto (token, assinatura, randomizador da mensagem e época da chave) é uma credencial ao portador que não está vinculada à solicitação de emissão.

As chaves públicas do emissor, agrupadas por época, são publicadas em:

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

Como um nó verifica um voucher

O aplicativo acrescenta uma extensão de voucher ao ClientHello da 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"
}

O nó analisa apenas esses campos. Ele busca as chaves públicas do emissor para a época no endpoint acima, as mantém em cache por uma hora e verifica a assinatura RSA-PSS SHA-384 randomizada. Ele não precisa de nenhum identificador de carteira nem de conta.

Modo de implantação: reject_invalid

• Vouchers malformados e criptograficamente inválidos são rejeitados antes de o handshake ser aceito.
• Uma conexão sem nenhum voucher ainda é aceita, para que os clientes mais antigos continuem funcionando. O uso de voucher ainda não é obrigatório.
• O nó não registra vouchers gastos. Os nós aceitam um voucher válido quantas vezes ele for apresentado, enquanto a época da chave do emissor continuar publicada. Os limites de compartilhamento, replay e cota são aplicados pelo backend, não pelo nó.

Os nós informam apenas resultados agregados:

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

O que o nó descobre sobre você

A garantia de que "o nó nunca descobre a identidade da sua carteira" vale somente para conexões com voucher.

• Conexões com voucher (o aplicativo oficial): o aplicativo se conecta com um voucher e uma chave de handshake nova e temporária. O nó consegue verificar o pagamento, mas não consegue vincular a sessão à sua carteira nem à sua identidade P2P.
• Conexões legadas: um cliente que se autentica com a sua chave de identidade em vez de um voucher envia essa chave no handshake.

Nos dois casos, o nó informa ao backend da AeroNyx a chave pública de handshake da sessão em um campo chamado client_wallet, junto com os horários da sessão e a contagem de bytes. Em uma conexão com voucher, esse valor é a chave temporária. Em uma conexão legada, é a chave de identidade do cliente. Os operadores de nós conseguem ver o tráfego por sessão e essas chaves no Nodeboard.

Os vouchers também não ocultam todo o resto. O nó ainda vê o seu endereço IP e, como saída, os seus destinos e o seu DNS, como qualquer VPN. Quando o aplicativo reserva uma conexão diária, o backend também registra que a conta se conectou naquele horário, mas não qual nó ela usou. Consulte a comparação de VPN e a Central de Confiança.

Admissão do Blind Vault (não implantada)

O Blind Vault é um componente do nó para armazenar objetos criptografados pelo cliente sob leases anônimas. Ele é descrito em MemChain e Blind Vault. O projeto da sua admissão:

• V2: o cliente cega uma mensagem de admissão RFC 9474. Um serviço de direitos autoriza a emissão, e um processo assinante separado (aeronyx-blind-issuer) assina apenas os bytes cegados. Esse processo não tem banco de dados de contas, armazenamento nem visibilidade dos resgates. O nó verifica a credencial finalizada com base em uma época de chave pública fixada e, em uma única transação SQLite, registra um marcador de gasto e cria uma lease aleatória e autoautenticada. Uma credencial gasta não pode criar uma segunda lease. Repetir exatamente a mesma solicitação retorna a mesma lease.
• V1: um ticket ao portador com a mesma tabela de gasto único. O nó armazena a identidade do ticket, então o resgate pode ser vinculado à emissão. Ele é mantido apenas por compatibilidade.

O nó só expõe estas rotas quando o Blind Vault e a sua API pública estão ambos ativados. Os dois vêm desativados por padrão.

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

Status atual: o Blind Vault não está implantado nos nós de produção, o aplicativo oficial não chama essas rotas, e o backend da AeroNyx não tem endpoint de direitos do Blind Vault. O Blind Vault não é um produto de backup, arquivamento nem armazenamento, e nenhum produto desse tipo é oferecido.

Observabilidade

As interfaces do operador mostram apenas a saúde agregada das credenciais:

• totais e proporções de valid, invalid, missing e malformed da VPN, e o modo de implantação
• disponibilidade das chaves do emissor e faixas aproximadas de falhas

Elas nunca mostram tokens de vouchers, assinaturas, randomizadores, mensagens cegadas nem IDs de gasto. O tráfego no nível de sessão e as chaves de handshake são uma visão separada do operador, descrita acima.

Modelo de ameaças e limites

As assinaturas cegas rompem o vínculo entre a solicitação de emissão e o voucher. Elas não eliminam estes riscos:

• correlação por temporização entre os registros de emissão ou de reserva de conexão do backend e os registros de sessão de um nó, especialmente quando uma mesma parte consegue ver ambos
• o nó ver o seu endereço IP, os seus destinos e o seu DNS
• roubo, compartilhamento ou revenda de vouchers enquanto a época da sua chave estiver publicada, porque os nós não aplicam o gasto único
• conexões sem voucher, que ainda são aceitas no modo reject_invalid
• erros na rotação das chaves do emissor ou clientes comprometidos

Mapa do código-fonte

O software de nó é de código aberto sob a AGPL-3.0, em github.com/AeroNyxNetwork/AeroNyx. O aplicativo não é de código aberto.

Perguntas frequentes

Um nó de VPN da AeroNyx sabe com qual carteira eu paguei?

Não em conexões com voucher, que são as usadas pelo aplicativo oficial. O nó verifica um voucher de assinatura cega e uma chave de handshake temporária, e nenhum dos dois está vinculado à sua carteira. Um cliente legado que se conecta com a sua chave de identidade revela essa chave ao nó.

Um voucher pode ser usado mais de uma vez?

Sim. Os nós verificam a assinatura com base na chave publicada para a época do voucher, mas não mantêm uma lista de vouchers gastos. As cotas são aplicadas pelo backend.

É necessário um voucher para se conectar?

Ainda não. Os nós rejeitam vouchers malformados ou inválidos, mas ainda aceitam conexões sem nenhum voucher, para que os clientes mais antigos continuem funcionando.

Onde as chaves do emissor de vouchers são publicadas?

Elas são publicadas em https://api.aeronyx.network/api/voucher/issuer/keys/, agrupadas por época. Os nós mantêm essas chaves em cache por uma hora.

O Blind Vault está disponível no aplicativo?

Não. A admissão do Blind Vault está implementada no software de nó, mas vem desativada por padrão, não está implantada e não é usada pelo aplicativo oficial. A AeroNyx não oferece nenhum produto de backup nem de armazenamento.