هر کاربری که ترافیک شبکه خود را از طریق تونل‌های اشتراکی VPN هدایت می‌کند، با چالش روبرو شدن مداوم با معماهای تصویری کپچا (CAPTCHA) آشنا است. هنگام باز کردن مستندات فنی، درگاه‌های پرداخت یا مخازن کد، یک مانع تکراری ظاهر می‌شود: جدولی از تصاویر که درخواست شناسایی خطوط عابر پیاده، چراغ‌های راهنمایی یا تایپ حروف ناخوانا را دارد.

ریشه این کندی در سامانه‌های خودکار تشخیص سوءاستفاده در گره‌های مرزی شبکه‌های توزیع محتوا (CDN) قرار دارد. موتورهای ارزیابی هوشمند، تراکم درخواست‌ها را از دامنه‌های IPv4 و پیشوندهای IPv6 بررسی می‌کنند. هنگامی که صدها کاربر از یک گیت‌وی خروجی مشترک استفاده می‌کنند، سامانه‌های حفاظتی هزاران اتصال همزمان را از یک آدرس واحد ثبت می‌کنند. الگوریتم این تراکم را رفتاری مشکوک تلقی کرده و آزمون تعاملی کپچا را فعال می‌کند.

برای سال‌ها، مدیران شبکه میان دو انتخاب نامناسب قرار داشتند: تحمیل حل مکرر آزمون‌های تصویری به کاربران، یا اختصاص آدرس‌های IP اختصاصی (که محافظت حاصل از ناشناسی گروهی را کاهش می‌دهد). تصویب استانداردهای IETF RFC 9505 (Privacy Pass Architecture) به همراه RFC 9506 و RFC 9578 راهکاری ریاضی و کارآمد ارائه کرده است: امضای دیجیتال کور (Blind Signatures) و توکن‌های دسترسی خصوصی (Private Access Tokens - PAT).

+--------------------------------------------------------------------------+
|                  معماری چهار بخشی استاندارد RFC 9505                     |
+--------------------------------------------------------------------------+
|                                                                          |
|    +------------+       1. تایید اصالت سخت‌افزار    +-------------+        |
|    |            | ------------------------------> | تاییدکننده  |        |
|    |   کلاینت   | <------------------------------ |  (Attester) |        |
|    | (مرورگر /  |         برگه تایید اعتبار       +-------------+        |
|    | WireGuard) |                                        |               |
|    |            |       3. ارسال توکن کور شده            | 2. ارسال      |
|    |            | ------------------------------> +-------------+ مدرک   |
|    |            | <------------------------------ | صادرکننده   |        |
|    +------------+       4. دریافت توکن امضا شده   |  (Issuer)   |        |
|          |                                        | (Blind RSA/ |        |
|          | 5. رفع کوری (Unblind)                  |   VOPRF)    |        |
|          |    و ارسال HTTP Authorization: PrivateToken          +        |
|          v                                                               |
|    +------------+                                                        |
|    |  سرور مقصد |  اعتبارسنجی امضا با کلید عمومی صادرکننده                |
|    | (لبه CDN)  |  دسترسی فوری و مستقیم بدون هیچگونه کپچا                 |
|    |            |  (سرور مقصد IP یا هویت کلاینت را دریافت نمی‌کند)       |
|    +------------+                                                        |
+--------------------------------------------------------------------------+

پایه‌های ریاضیاتی: امضای کور و توابع VOPRF

نوآوری بنیادین RFC 9505 در جداسازی کامل فرآیند صدور توکن از فرآیند استفاده از آن نهفته است. در سازوکارهای سنتی هویت نظیر OAuth یا گواهی‌های x509، صادرکننده دقیقاً می‌داند چه کسی توکن را دریافت کرده و آن را در چه سایتی ارائه می‌دهد. در صورت تبادل گزارش‌ها میان صادرکننده و سرور مقصد، مسیر وبگردی کاربر با دقت بازسازی می‌شود.

پروتکل Privacy Pass این پیوند را از طریق امضاهای کور (RFC 9506) و توابع شبه‌تصادفی پنهان تاییدپذیر (VOPRF، RFC 9578) قطع می‌کند. این فرآیند در پنج گام اجرایی خلاصه می‌شود:

1. مرحله کورسازی (Blinding)

هنگامی که کلاینت پاسخ HTTP 401 Unauthorized را همراه با سرآیند WWW-Authenticate: PrivateToken دریافت می‌کند، یک مقدار تصادفی امن $x$ برای چالش و یک عدد اسکالر کورکننده $r$ تولید می‌کند.

روی یک خم بیضوی (مانند NIST P-256 یا Curve25519) با نقطه پایه $G$، کلاینت مقدار $x$ را به نقطه خم $M = H_{1}(x)$ بر اساس RFC 9380 تبدیل می‌کند. سپس نقطه کور شده $B$ محاسبه می‌شود:

$$B = r \cdot M$$

به دلیل دشواری مسئله لگاریتم گسسته روی خم‌های بیضوی، هیچ ناظری با دیدن $B$ نمی‌تواند مقدار اولیه $M$ یا فاکتور $r$ را به دست آورد.

2. مرحله صدور توکن (Issuance)

نقطه کور شده $B$ به صادرکننده (Issuer) ارسال می‌شود. برای جلوگیری از تولید انبوه توکن توسط شبکه‌های ربات، صادرکننده به تایید یک نهاد مستقل به نام تاییدکننده (Attester) متکی است. در سیستم‌عامل‌های مدرن، تاییدکننده (نظیر Apple Secure Enclave یا تراشه TPM) تایید می‌کند:

  • دستگاه یک سخت‌افزار واقعی است و نه یک شبیه‌ساز ابری؛
  • هسته سیستم‌عامل دستکاری نشده است؛
  • تعداد درخواست‌های اخیر دستگاه در محدوده مجاز قرار دارد.

تاییدکننده فقط سلامت فیزیکی دستگاه را ارزیابی می‌کند و هیچ اطلاعاتی از نقطه کور شده $B$ یا نام سایت مقصد ندارد. پس از تایید، صادرکننده نقطه کور را با کلید خصوصی $k$ امضا می‌کند:

$$C = k \cdot B = k \cdot (r \cdot M)$$

صادرکننده همچنین اثبات برابری لگاریتم گسسته (DLEQ) را پیوست می‌کند تا اثبات کند $C$ با کلید عمومی $K = k \cdot G$ همخوانی دارد.

3. مرحله رفع کوری و اعتبارسنجی (Unblinding & Verification)

با دریافت $C$ و اثبات DLEQ، کلاینت صحت ریاضی را با کلید عمومی صادرکننده می‌سنجد. سپس فاکتور $r$ را با ضرب در معکوس ماژولار $r$ حذف می‌کند:

$$S = r^{-1} \cdot C = r^{-1} \cdot (k \cdot r \cdot M) = k \cdot M$$

نقطه حاصل $S$ یک امضای کاملاً معتبر روی پیام اصلی $M = H_{1}(x)$ است. کلاینت این امضا را در قالب یک توکن باینری RFC 9505 بسته‌بندی کرده و درخواست HTTP را با سرآیند Authorization: PrivateToken token="..." مجدداً ارسال می‌کند.

سرور مقصد:

  1. مقدار $M = H_{1}(x)$ را محاسبه می‌کند؛
  2. رابطه جبری خم بیضوی را با کلید عمومی $K$ بررسی می‌کند؛
  3. مقدار $x$ را در حافظه جلوگیری از تکرار (replay cache) ثبت می‌کند تا از مصرف مجدد جلوگیری شود.

درخواست بدون تاخیر تایید می‌شود. سرور مقصد متوجه می‌شود که این درخواست از یک دستگاه تایید شده ارسال شده است، بدون اینکه از هویت یا آدرس شبکه آن مطلع شود. همزمان، صادرکننده فقط داده‌های کور شده $B$ را مشاهده کرده بود و هیچ دانشی درباره وب‌سایت مورد بازدید ندارد.

+--------------------------------------------------------------------------+
|                       جدول تفکیک دسترسی اطلاعات                          |
+--------------------------------------------------------------------------+
| بخش فعال     | آیا IP واقعی را می‌داند؟ | آیا سایت مقصد را می‌داند؟| نوع OS؟ |
+-------------+--------------------------+--------------------------+---------+
| تاییدکننده  | بله (یا IP خروجی VPN)    | خیر                      | بله     |
| صادرکننده   | خیر                      | خیر                      | خیر     |
| سرور CDN    | بله (IP خروجی VPN)       | بله (سایت خودش)          | خیر     |
| رله VPN     | بله (IP ورودی)           | بله (IP سرور CDN)        | خیر     |
+--------------------------------------------------------------------------+

استفاده از Private Access Tokens (PAT) در اکوسیستم وب

در محیط‌های کاربردی وب، استاندارد RFC 9505 با عنوان Private Access Tokens (PAT) پیاده‌سازی شده است. این فناوری به طور پیش‌فرض در iOS 16، macOS 13، اندروید و سرویس‌های سیستمی لینوکس فعال بوده و توسط شبکه‌های CDN مانند Cloudflare و Fastly پشتیبانی می‌شود.

تبادل پیام در پروتکل HTTP به این شکل انجام می‌گیرد:

GET /api/v1/telemetry HTTP/1.1
Host: api.example.com
User-Agent: SecureClient/2.4

HTTP/1.1 401 Unauthorized
Date: Fri, 13 Nov 2026 02:14:00 GMT
WWW-Authenticate: PrivateToken challenge="AQAB...", token-key="BLz..."

سرآیند WWW-Authenticate دو پارامتر ارسال می‌کند:

  • challenge: ساختار باینری base64url که نوع توکن (0x0002 برای امضای کور یا 0x0001 برای VOPRF) و شناسه مبدا را مشخص می‌کند.
  • token-key: هش اثر انگشت SHA-256 از کلید عمومی معتبر صادرکننده.

مرورگر پاسخ 401 را در لایه‌های زیرین پردازش کرده و بدون وقفه در نمایش صفحه، چرخه تایید اعتبار را به انجام می‌رساند:

GET /api/v1/telemetry HTTP/1.1
Host: api.example.com
Authorization: PrivateToken token="AQIDBA..."

درگاه مرزی امضا را در کسری از میلی‌ثانیه بررسی کرده، امتیاز ریسک را صفر می‌کند و محتوا را با کد HTTP 200 OK بازمی‌گرداند.

هم‌افزایی با معماری تونل‌های لایه ۳ پروتکل RiceGuard

گرچه Privacy Pass در لایه کاربرد (L7) اجرا می‌شود، هماهنگی آن با تونل‌های شبکه لایه ۳ (L3) مزایای عملیاتی چشمگیری ایجاد می‌کند:

  1. تفکیک مسیرهای احراز هویت: هنگام ارسال ترافیک از بستر VPNRice و پروتکل RiceGuard، ارتباط با تاییدکننده با تدابیر ضد نشت DNS محافظت می‌شود. آدرس ثبت شده در تاییدکننده با آدرس مشاهده شده در سرور مقصد متفاوت است و امکان تحلیل همبستگی ترافیک را مسدود می‌کند.
  2. کاهش محدودیت‌های IP اشتراکی: سرورهای VPN اشتراکی از مزایای اعتماد مبتنی بر توکن بهره‌مند می‌شوند. نیازی به تعویض مکرر آدرس‌های IP برای جلوگیری از مسدودسازی توسط CDNها نخواهد بود.
  3. محافظت در برابر انگشت‌نگاری دیجیتال (Fingerprinting): کپچاهای متداول اسکریپت‌های سنگین جاوااسکریپت را برای استخراج ویژگی‌های گرافیکی Canvas و WebGL اجرا می‌کنند. با جایگزینی این روند با توکن‌های PAT، دستگاه از اجرای کدهای غیرضروری پایش مصون می‌ماند.

نمونه کد ارزیابی توکن در درگاه خدمات (زبان Go)

برای توسعه‌دهندگان گیت‌وی‌های شبکه، اعتبارسنجی توکن‌های RFC 9505 به منابع پردازشی بسیار اندکی نیاز دارد. نمونه کد زیر به زبان Go نحوه ارزیابی سرآیند PrivateToken را نشان می‌دهد:

package main

import (
	"crypto"
	"crypto/rsa"
	"crypto/sha256"
	"encoding/base64"
	"errors"
	"fmt"
	"net/http"
	"strings"
	"sync"
)

type TokenValidator struct {
	issuerPublicKey *rsa.PublicKey
	spentTokens     map[string]bool
	mu              sync.Mutex
}

func NewTokenValidator(pubKey *rsa.PublicKey) *TokenValidator {
	return &TokenValidator{
		issuerPublicKey: pubKey,
		spentTokens:     make(map[string]bool),
	}
}

// VerifyPrivateToken صحت توکن باینری RFC 9505 را بررسی می‌کند
func (v *TokenValidator) VerifyPrivateToken(rawHeader string) error {
	if !strings.HasPrefix(rawHeader, "PrivateToken token=") {
		return errors.New("سرآیند PrivateToken نامعتبر است")
	}

	tokenData := strings.TrimPrefix(rawHeader, "PrivateToken token=")
	tokenData = strings.Trim(tokenData, """)
	decoded, err := base64.RawURLEncoding.DecodeString(tokenData)
	if err != nil {
		return fmt.Errorf("خطای دیکود base64: %w", err)
	}

	// ساختار باینری توکن (نوع 0x0002):
	// [2 بایت نوع] [32 بایت بافت] [32 بایت عدد تصادفی] [256 بایت امضا]
	if len(decoded) < 2+32+32+256 {
		return errors.New("طول داده توکن کمتر از حد مجاز است")
	}

	tokenType := uint16(decoded[0])<<8 | uint16(decoded[1])
	if tokenType != 0x0002 {
		return fmt.Errorf("نوع توکن پشتیبانی نمی‌شود: 0x%04x", tokenType)
	}

	context := decoded[2:34]
	nonce := decoded[34:66]
	signature := decoded[66 : 66+256]

	nonceKey := fmt.Sprintf("%x", nonce)

	// جلوگیری از استفاده مجدد توکن
	v.mu.Lock()
	if v.spentTokens[nonceKey] {
		v.mu.Unlock()
		return errors.New("این توکن قبلاً مصرف شده است")
	}
	v.spentTokens[nonceKey] = true
	v.mu.Unlock()

	// محاسبه خلاصه پیام: Hash(بافت || عدد تصادفی)
	h := sha256.New()
	h.Write(context)
	h.Write(nonce)
	digest := h.Sum(nil)

	// اعتبارسنجی امضای RSA-PSS با کلید عمومی صادرکننده
	err = rsa.VerifyPSS(v.issuerPublicKey, crypto.SHA256, digest, signature, &rsa.PSSOptions{
		SaltLength: rsa.PSSSaltLengthEqualsHash,
	})
	if err != nil {
		return fmt.Errorf("اعتبارسنجی رمزنگاری ناموفق بود: %w", err)
	}

	return nil
}

func (v *TokenValidator) Middleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		authHeader := r.Header.Get("Authorization")
		if authHeader == "" || v.VerifyPrivateToken(authHeader) != nil {
			w.Header().Set("WWW-Authenticate", `PrivateToken challenge="AQAC...", token-key="pub-sha256"`)
			w.WriteHeader(http.StatusUnauthorized)
			w.Write([]byte("401 Unauthorized: ارائه توکن معتبر RFC 9505 الزامی است\n"))
			return
		}
		next.ServeHTTP(w, r)
	})
}

چالش‌های ساختاری و چشم‌انداز آینده

استاندارد RFC 9505 الگوی جدیدی برای امنیت وب فراهم می‌آورد که در آن اعتماد بر مبنای اندازه‌گیری‌های سخت‌افزاری و ریاضیات کورسازی شکل می‌گیرد نه نظارت رفتاری. در زمان پیاده‌سازی زیرساخت، توجه به نکات زیر ضروری است:

  • تنوع مراجع تایید: در حال حاضر بخش عمده تاییدکنندگان توسط تولیدکنندگان اصلی پلتفرم‌ها (اپل و گوگل) ارائه می‌شوند. در توزیع‌های لینوکس و نرم‌افزارهای آزاد، توسعه پروتکل‌های مبتنی بر تراشه‌های باز TPM و استانداردهای WebAuthn ضرورت دارد.
  • کنترل سقف مصرف توکن: برای جلوگیری از سوءاستفاده از یک دستگاه فیزیکی جهت اخذ حجم بالایی از توکن‌ها، صادرکنندگان از الگوریتم سطل توکن (token bucket) استفاده می‌کنند. تنظیم دقیق این سهمیه‌ها در گیت‌وی‌های پرمصرف VPN حائز اهمیت است.
  • جداسازی کامل نهادها: عدم تبادل اطلاعات بین تاییدکننده، صادرکننده و سرور مقصد اصل اساسی است. این طرف‌ها باید در دامنه‌های مستقل با تدابیر بازرسی رمزنگاری شده فعالیت کنند.

استاندارد RFC 9505 و توکن‌های PAT ثابت می‌کنند که ارتقای امنیت شبکه و حفظ حریم خصوصی کاربران از طریق راهکارهای رمزنگاری نوین کاملاً قابل تحقق است.