الخلاصة

  • يثبت نمطا الإصدار في RFC 9578 تطابق الموثّق مع مدخل الرمز ومفتاح جهة الإصدار، ولا يحوّلان ذلك التطابق إلى شهادة هوية أو استحقاق.
  • معنى التحدي وحالة الاسترداد وسياسة المصدر والنتيجة التي تلقاها المستخدم قرارات منفصلة، ويجب أن يترك كل منها إيصالاً قابلاً للمراجعة.

يمكن لنظام أن يحمي خصوصية الرمز جيداً ثم يسيء فهمه تماماً. فالخصوصية تقلل ما يمكن ربطه، لكنها لا تمنح الدليل سلطة أوسع مما صُمم لإثباته.

تضع RFC 9578 الحد بوضوح: لا تثبت رموز Privacy Pass شيئاً سوى أن خادماً معيناً أنشأها في وقت سابق. ويؤكد سجل RFC Editor وصفحة Datatracker وتاريخ الوثيقة وبحث التصحيحات هوية المعيار وحالته. ولا يثبت أي منها إصداراً بعينه أو جودة نشر أو قرار وصول.

الثقة تبدأ قبل إنشاء الرمز

تبدأ العملية بتهيئة جهة الإصدار: نوع الرمز واسم الجهة ونقطة الطلب، ومع النمط القابل للتحقق العام مفتاح التحقق العلني. مصدر هذه التهيئة وحداثتها وبصمتها واتساقها يحدد المفتاح الذي سيُعامل لاحقاً بوصفه سلطة.

يستخدم النمط القابل للتحقق الخاص VOPRF على P-384 وSHA-384، ولا يستطيع التحقق من الرمز النهائي إلا من يملك المفتاح الخاص لجهة الإصدار. أما النمط العام فيستخدم RSA أعمى بمعامل 2048 بت، ويتيح التحقق بالمفتاح العام. تعرّف RFC 9497 آلية VOPRF، وتعرّف RFC 9474 توقيعات RSA العمياء.

ينشئ العميل nonce جديداً من 32 بايت، ويحسب SHA-256 لتحدٍ مبهم، ويضيف معرّف المفتاح، ثم يعمي مدخل الرمز. تتحقق جهة الإصدار من البنية والنوع المدعوم، وتقيّم العنصر المعمى أو توقّعه، ثم ترسل الاستجابة. ويحوّلها العميل في خطوة الإنهاء إلى موثّق الرمز.

لا تحتاج جهة الإصدار بذلك إلى رؤية الرمز النهائي عند الإصدار. لكن التوقيت الشبكي وسياق الحساب وإشارات جهة الإثبات ومسار التهيئة وبيانات المصدر وسيطرة مؤسسة واحدة على أدوار متعددة تبقى خارج العنصر المعمى. إخفاء المدخل خاصية بروتوكولية؛ أما عدم قابلية الربط في نشر فعلي فادعاء يحتاج قياساً مستقلاً.

ربط التحدي لا يثبت إنجازه

تعامل RFC 9578 التحدي كمدخل مبهم. وقد يأتي من مسار المصادقة والاسترداد في RFC 9577. يربط التجزئة الرمز ببايتات محددة، لكنه لا يثبت أن وصف تلك البايتات صحيح أو أن الشرط المعلن قد تحقق.

إذا قيل إن التحدي يمثل اجتياز CAPTCHA أو إثبات جهاز أو شراء حصة، فعلى المكوّن الذي فحص ذلك الشرط أن يقدم إيصالاً خاصاً به. يثبت الإصدار أن البروتوكول عالج المدخل المعطى؛ ولا يستطيع صنع دليل لم تحتفظ به المرحلة السابقة.

تفصل معمارية Privacy Pass في RFC 9576 بين العميل والمصدر وجهة الإثبات وجهة الإصدار، وتناقش البيانات الوصفية والتواطؤ. وهي خريطة لتصميم الحدود، وليست شهادة بأن مشغلاً محدداً فصل الأدوار فعلاً. تبقى تغطية BTW السابقة لـ RFC 9614 مالكة لمسألة الفصل المعماري وعدم قابلية الربط؛ ويتتبع هذا المقال سلسلة أخرى من الإصدار إلى النتيجة.

التحقق يسبق الاسترداد والتفويض والنتيجة

في النمط الخاص تعيد جهة الإصدار حساب خرج VOPRF بسرها. وفي النمط العام يفحص المتحقق التوقيع بالمفتاح العام. تجيب النتيجة الناجحة عن توافق الموثّق مع المدخل والمفتاح. ولا تجيب عما إذا كان جميع العملاء رأوا المفتاح نفسه، أو كان الرمز جديداً، أو سبق استرداده، أو بقيت حصة، أو كان الفعل المطلوب مسموحاً.

لهذا يلزم مخزن استرداد وسياسة لدى المصدر. ينسق سجل IANA لـ Privacy Pass الأنواع وصيغ الوسائط، لكن التسجيل لا يثبت الانتشار ولا يمنح التفويض. ويوضح العمل الحالي على اتساق مفاتيح جهة الإصدار ورموز تحديد المعدل أن رؤية المفاتيح ومعنى الحصة مشكلتان بروتوكوليتان مستقلتان. وهما مسودتان حاليتان، لا إجماع RFC ولا دليل تشغيل.

يجب أن تربط سلسلة قابلة للتدقيق مصدر التهيئة وبصمتها، ومعرّف المفتاح، وبايتات التحدي ونسخة سياسته، وnonce وبصمة المدخل، واستجابة الإصدار، وإنهاء العميل، وهوية المتحقق واختيار المفتاح، وقرار مخزن الاسترداد، وحالة الإعادة، وسبب التفويض، وحالة الاستجابة، والنتيجة الفعلية. تتطلب الخصوصية تقليل الربط، لا دمج سلطات مختلفة في إشارة نجاح واحدة.

تمنع مقالة Heng Lu عن طبقات الواقع الصلاحية التشفيرية من ابتلاع سلطة السياسة. وتعيد Running-Code Primacy الحقيقة التشغيلية إلى سلوك المكونات المشاهَد. أما سبب وجود BTW Media فيضع القاعدة التحريرية: ننشر المعنى الضيق الذي كسبه الإيصال، لا النتيجة المطمئنة التي ترغب المؤسسة في إسنادها إليه.

المصادر