القسائم الموقّعة توقيعًا أعمى وبيانات اعتماد الوصول المجهولة
كيف تتيح قسائم VPN في AeroNyx للعقدة التحقق من الدفع دون معرفة الحساب الدافع، وما الذي لا يزال الطرح التدريجي بوضع reject_invalid يسمح به، وما الذي لا تزال العقدة والواجهة الخلفية تريانه، ولماذا القبول في Blind Vault مُنفَّذ لكنه غير منشور.
تستخدم AeroNyx قسائم موقّعة توقيعًا أعمى لكي تتمكن عقدة VPN من التحقق من أن الاتصال مدفوع الثمن دون أن تعرف الحساب الذي دفع. هذه الآلية قيد التشغيل الفعلي لـ VPN اليوم، في وضع توافق لا يزال يقبل الاتصالات دون قسيمة. ويوجد مسار ثانٍ لبيانات الاعتماد، هو القبول في Blind Vault، ضمن برنامج العُقد، لكنه غير منشور ولا يستخدمه التطبيق الرسمي.
مساران لبيانات الاعتماد
| مسار بيانات الاعتماد | الحالة | نموذج الاسترداد |
|---|---|---|
| قسيمة مصافحة VPN | قيد التشغيل الفعلي. تعمل في وضع التوافق reject_invalid | تتحقق العقدة من التوقيع. ولا تتتبّع الإنفاق لمرة واحدة |
| القبول في Blind Vault V2 | مُنفَّذ في العقدة. غير منشور، ولا يستخدمه التطبيق الرسمي | إنفاق لمرة واحدة يُسجَّل ذريًا مع إنشاء عقد الإيجار |
| القبول في Blind Vault V1 | للتوافق فقط، ضمن المكوّن المعطّل نفسه | إنفاق لمرة واحدة، لكن يمكن ربط الإصدار بالاسترداد |
كيف تُصدر قسيمة VPN
- يولّد التطبيق رمزًا عشوائيًا بطول 32 بايت ويُعمّيه محليًا، باستخدام توقيعات RSA العمياء (RSABSSA-SHA384-PSS-Randomized، RFC 9474).
- يرسل التطبيق الرسالة المُعمّاة فقط إلى الواجهة الخلفية لـ AeroNyx على
/api/voucher/issue/. تتحقق الواجهة الخلفية من أن الحساب المسجّل الدخول مستحق، وتوقّع الرسالة المُعمّاة وتعيد التوقيع. ولا ترى الرمز أبدًا. - يُتمّ التطبيق التوقيع محليًا. والقسيمة المكتملة (الرمز، والتوقيع، ومُعشّي الرسالة، وحقبة المفتاح) بيانات اعتماد لحاملها غير مرتبطة بطلب الإصدار.
تُنشر مفاتيح الجهة المُصدِرة العامة، مجمّعة حسب الحقبة، على:
GET https://api.aeronyx.network/api/voucher/issuer/keys/
كيف تتحقق العقدة من القسيمة
يُلحق التطبيق امتداد قسيمة برسالة 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"
}
لا تحلّل العقدة إلا هذه الحقول. تجلب المفاتيح العامة للجهة المُصدِرة الخاصة بالحقبة من نقطة النهاية المذكورة أعلاه، وتخزّنها مؤقتًا لمدة ساعة واحدة، وتتحقق من توقيع RSA-PSS المعشّى باستخدام SHA-384. ولا تحتاج إلى أي معرّف للمحفظة أو الحساب.
وضع الطرح التدريجي: reject_invalid
- تُرفض القسائم المشوّهة وغير الصالحة تشفيريًا قبل قبول المصافحة.
- لا يزال الاتصال الذي لا يتضمن أي قسيمة على الإطلاق مقبولًا، لكي تستمر العملاء الأقدم في العمل. واستخدام القسائم ليس إلزاميًا بعد.
- لا تسجّل العقدة القسائم المُنفَقة. تقبل العُقد القسيمة الصالحة في كل مرة تُقدَّم فيها، ما دامت حقبة مفتاح الجهة المُصدِرة الخاصة بها لا تزال منشورة. وتفرض الواجهة الخلفية، لا العقدة، حدود المشاركة وإعادة الاستخدام والحصص.
لا تُبلغ العُقد إلا عن النتائج المجمّعة:
mode = reject_invalid
valid | invalid | missing | malformed | total
valid_ratio | invalid_ratio | missing_ratio | malformed_ratio
last_observation | last_error
ما تعرفه العقدة عنك
يسري الضمان القائل إن "العقدة لا تعرف أبدًا هوية محفظتك" على الاتصالات بالقسائم فقط.
- الاتصالات بالقسائم (التطبيق الرسمي): يتصل التطبيق بقسيمة ومفتاح مصافحة مؤقت جديد. يمكن للعقدة التحقق من الدفع، لكنها لا تستطيع ربط الجلسة بمحفظتك أو بهوية P2P الخاصة بك.
- الاتصالات القديمة: العميل الذي يصادق بمفتاح هويته بدلًا من قسيمة يرسل ذلك المفتاح في المصافحة.
في الحالتين، تُبلغ العقدة الواجهة الخلفية لـ AeroNyx بالمفتاح العام لمصافحة الجلسة في حقل يُسمّى client_wallet، إلى جانب أوقات الجلسة وأعداد البايتات. في الاتصال بقسيمة، تكون تلك القيمة هي المفتاح المؤقت. وفي الاتصال القديم، تكون مفتاح هوية العميل. ويمكن لمشغّلي العُقد رؤية حركة المرور لكل جلسة وهذه المفاتيح في Nodeboard.
كما أن القسائم لا تخفي كل شيء آخر. فلا تزال العقدة ترى عنوان IP الخاص بك، وبوصفها نقطة الخروج، ترى وجهاتك وDNS، مثل أي VPN. وعندما يحجز التطبيق اتصالًا يوميًا، تسجّل الواجهة الخلفية أيضًا أن الحساب اتصل في ذلك الوقت، لكنها لا تسجّل العقدة التي استخدمها. راجع مقارنة VPN ومركز الثقة.
القبول في Blind Vault (غير منشور)
Blind Vault مكوّن في العقدة لتخزين كائنات مشفّرة من جانب العميل بموجب عقود إيجار مجهولة. وهو موصوف في MemChain وBlind Vault. وتصميم القبول فيه كما يلي:
- V2: يُعمّي العميل رسالة قبول وفق RFC 9474. تأذن خدمة استحقاق بالإصدار، وتوقّع عملية توقيع منفصلة (
aeronyx-blind-issuer) البايتات المُعمّاة فقط. وليس لتلك العملية قاعدة بيانات حسابات ولا تخزين ولا اطلاع على عمليات الاسترداد. تتحقق العقدة من بيانات الاعتماد المكتملة مقابل حقبة مفتاح عام مثبّتة، وفي معاملة SQLite واحدة، تسجّل علامة إنفاق وتُنشئ عقد إيجار عشوائيًا ذاتي المصادقة. ولا يمكن لبيانات اعتماد مُنفَقة إنشاء عقد إيجار ثانٍ. وإعادة محاولة الطلب نفسه تمامًا تعيد عقد الإيجار نفسه. - V1: تذكرة لحاملها مع جدول الإنفاق لمرة واحدة نفسه. تخزّن العقدة هوية التذكرة، لذا يمكن ربط الاسترداد بالإصدار. ولا يُحتفظ بها إلا للتوافق.
لا تكشف العقدة هذه المسارات إلا عندما يكون Blind Vault وواجهته البرمجية العامة مفعّلين كلاهما. وكلاهما معطّل افتراضيًا.
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
الحالة الراهنة: Blind Vault غير منشور على عُقد الإنتاج، ولا يستدعي التطبيق الرسمي هذه المسارات، وليس لدى الواجهة الخلفية لـ AeroNyx نقطة نهاية لاستحقاقات Blind Vault. وBlind Vault ليس منتجًا للنسخ الاحتياطي أو الأرشفة أو التخزين، ولا يُقدَّم أي منتج من هذا النوع.
إمكانية المراقبة
لا تعرض واجهات المشغّلين إلا السلامة المجمّعة لبيانات الاعتماد:
- إجماليات
validوinvalidوmissingوmalformedلـ VPN ونسبها، ووضع الطرح التدريجي - توفّر مفاتيح الجهة المُصدِرة وفئات تقريبية لحالات الفشل
ولا تعرض أبدًا رموز القسائم أو التوقيعات أو المُعشّيات أو الرسائل المُعمّاة أو معرّفات الإنفاق. أما حركة المرور على مستوى الجلسة ومفاتيح المصافحة فهي عرض منفصل للمشغّلين، موصوف أعلاه.
نموذج التهديد والحدود
تقطع التوقيعات العمياء الصلة بين طلب الإصدار والقسيمة. لكنها لا تزيل المخاطر التالية:
- الربط عبر التوقيت بين سجلات الإصدار أو حجز الاتصالات في الواجهة الخلفية وسجلات الجلسات في العقدة، لا سيما حين يستطيع طرف واحد رؤية كليهما
- رؤية العقدة لعنوان IP الخاص بك ووجهاتك وDNS
- سرقة القسائم أو مشاركتها أو إعادة بيعها ما دامت حقبة مفتاحها منشورة، لأن العُقد لا تفرض الإنفاق لمرة واحدة
- الاتصالات دون قسيمة، التي لا تزال مقبولة في وضع
reject_invalid - أخطاء تدوير مفاتيح الجهة المُصدِرة أو العملاء المخترقون
خريطة المصدر
| الطبقة | المسار في مستودع العقدة | الدور |
|---|---|---|
| مُتحقِّق VPN | crates/aeronyx-server/src/voucher_verifier.rs | يحلّل AVCH، ويجلب مفاتيح الحقب، ويتحقق من القسائم، ويسجّل النتائج المجمّعة |
| المُوقِّع الأعمى | crates/aeronyx-blind-issuer/src/signer.rs، api.rs | توقيع RSA أعمى خالٍ من الهوية لـ Blind Vault V2 |
| عقود الصيغة السلكية | crates/aeronyx-core/src/protocol/blind_vault.rs | رسائل القبول وفق RFC 9474، وحقب المفاتيح، ومعرّفات الإنفاق |
| خدمة Blind Vault وواجهتها البرمجية | crates/aeronyx-server/src/services/blind_vault.rs، api/blind_vault.rs | القبول، والإنفاق وعقد الإيجار الذريان، ومسارات الكائنات |
| إعدادات Blind Vault | crates/aeronyx-server/src/config_blind_vault.rs | معطّل افتراضيًا؛ قواعد تثبيت الجهة المُصدِرة وتدويرها |
برنامج العُقد مفتوح المصدر بموجب AGPL-3.0 على github.com/AeroNyxNetwork/AeroNyx. أما التطبيق فليس مفتوح المصدر.
<!-- faq:start -->الأسئلة الشائعة
هل تعرف عقدة VPN في AeroNyx المحفظة التي دفعت بها؟
ليس في الاتصالات بالقسائم، التي يستخدمها التطبيق الرسمي. تتحقق العقدة من قسيمة موقّعة توقيعًا أعمى ومن مفتاح مصافحة مؤقت، ولا يرتبط أي منهما بمحفظتك. أما العميل القديم الذي يتصل بمفتاح هويته فيكشف ذلك المفتاح للعقدة.
هل يمكن استخدام القسيمة أكثر من مرة؟
نعم. تتحقق العُقد من التوقيع مقابل المفتاح المنشور لحقبة القسيمة، لكنها لا تحتفظ بقائمة للقسائم المُنفَقة. وتفرض الواجهة الخلفية الحصص.
هل القسيمة مطلوبة للاتصال؟
ليس بعد. ترفض العُقد القسائم المشوّهة أو غير الصالحة، لكنها لا تزال تقبل الاتصالات دون أي قسيمة، لكي تستمر العملاء الأقدم في العمل.
أين تُنشر مفاتيح الجهة المُصدِرة للقسائم؟
تُنشر على https://api.aeronyx.network/api/voucher/issuer/keys/، مجمّعة حسب الحقبة. وتخزّن العُقد هذه المفاتيح مؤقتًا لمدة ساعة واحدة.
هل Blind Vault متاح في التطبيق؟
لا. القبول في Blind Vault مُنفَّذ في برنامج العُقد، لكنه معطّل افتراضيًا، وغير منشور، ولا يستخدمه التطبيق الرسمي. ولا تقدّم AeroNyx أي منتج للنسخ الاحتياطي أو التخزين.
<!-- faq:end -->