الخلاصة
- توضح بنية Key Transparency الحالية أن جميع طلبات المستخدم وبراهينه قد تكون صحيحة، بينما يعرض السجل لمستخدمين آخرين رؤية غير متوافقة. الاتساق يبقي العميل على فرعه، لكنه لا يخبره وحده بوجود فرع آخر.
- يحتاج الكشف إلى قناة مقارنة مستقلة: مدقق أو مدير لا يتواطأ مع السجل، أو وصول مجهول، أو تبادل بين الأقران. وكل خيار يعيد توزيع الثقة والخصوصية وحالة العميل ومسؤولية التشغيل.
أكثر الأعطال هدوءا قد يبدو متسقا تماما
المشهد الافتتاحي افتراض تشغيلي وليس تقريرا عن حادثة وقعت. وهو يفصل بين سؤالين: هل تمتد هذه الإجابة بصورة صحيحة مما شاهده جهازي سابقا؟ وهل شاهد جميع المستخدمين التاريخ نفسه؟ يمكن حساب الأول محليا، أما الثاني فيحتاج إلى نقطة مراقبة خارج القناة المعزولة.
تعالج الوثيقة draft-ietf-keytrans-architecture-09 هذا الفرق بوضوح. يسجلها Datatracker لدى IETF كمسودة إنترنت نشطة. نُشرت المراجعة 09 في 29 يونيو 2026، وحُدث الملف في 9 يوليو. حالة مجموعة العمل هي Submitted to IESG for Publication، وحالة IESG هي Publication Requested، والصفة المقصودة Informational، ولا يوجد موعد telechat. لذلك فهي ليست RFC معتمدة ولا نصا نهائيا.
تبدأ المشكلة قبل السجل. يستطيع التشفير من طرف إلى طرف حماية محتوى الرسالة، مع بقاء الدليل الذي يربط هوية مرئية بمفتاح عام تحت سيطرة مشغل الخدمة. فإذا استبدل المشغل المفتاح بآخر يملكه، قد تبقى الجلسة مشفرة لكن هوية الطرف المقابل تكون قد تغيرت.
يضع Key Transparency تلك الروابط في سجل إضافة فقط محمي بالتشفير. تعيد عملية Search قيمة الوسم وبرهانه، وتضيف Update نسخة جديدة، وتراقب Monitor بقاء النتائج القديمة وعدم تغيير أوسمة المستخدم من دون علمه. هذه طبقة تنسيق ضيقة تجعل التاريخ قابلا للتحقق، ولا تنقل كل صلاحيات التطبيق إلى السجل.
مع ذلك يستطيع سجل خبيث عرض تاريخ لسلمى وآخر لعمر. يشترط كل عميل أن تتسق الإجابة التالية مع رأس الشجرة الذي خزنه، فيبقى على رؤية خطية ويرفض لاحقا ما يناقضها. يمنع ذلك محو الانقسام بدمج صامت، ويحفظ فرصة لإثباته. لكنه لا يجعل أحد الطرفين يعرف ما عرضه السجل للطرف الآخر.
المقارنة وظيفة أمنية منفصلة
تحدد المسودة ثلاثة طرق لعبور العزل: طرف ثالث موثوق، واتصال مجهول بالسجل، واتصال مباشر بين الأقران. جميعها تضيف رؤية لا تأتي من القناة الموثقة التي ربما عزلها الخصم.
في تدقيق الطرف الثالث، يتابع المدقق نمو السجل ويوقع رأسا حديثا للشجرة. يرفق السجل التوقيع بإجابات المستخدم. يعتمد الأمان على عدم تواطؤ المدقق والسجل لتوقيع الفرع الخاطئ. وغالبا ما يعمل التدقيق بصورة غير متزامنة، لذلك قد يتأخر التوقيع عن أحدث حالة. الحد المقبول لهذا التأخير قرار إعداد وحوكمة، وليس رقما تفرضه الخوارزمية.
أما إدارة الطرف الثالث فتنقل قدرا أكبر من العمل. يحتفظ المدير بمعظم السجل ويشغله، بينما تطبق الخدمة التحكم في الوصول وتصادق على نسخ الأوسمة الجديدة. يبقى عدم التواطؤ شرطا، ويجب على المشغل اكتشاف الانقسامات التي يقدمها المدير. يمكن لعدة أطراف مستقلة استخدام توقيع عتبة، لكن اختيار الأعضاء وتدوير المفاتيح واستبدال العضو الغائب قرارات مؤسسية.
لا يعتمد Contact Monitoring على شاهد مؤسسي دائم. يفحص مالك الوسم قيمته الحالية دوريا، ويعود من رأى قيمة حديثة لاحقا ليتأكد من أنها لم تُحذف قبل أن يلاحظها المالك. ويظل التطبيق مطالبا بمقارنة مجهولة أو بين الأقران لكشف الانقسام. تنتقل الكلفة إلى الأجهزة ومدة اتصال المستخدمين وشبكة اللقاءات بينهم.
يحصل الفحص المجهول على رأس شجرة عبر مسار لا يكشف هوية السائل، ثم يقارنه بما ظهر في المسار الموثق. لا يستطيع السجل الذي يحافظ على فروع عدة أن يعرف بثقة أي فرع يعيده. يزيد التكرار احتمال الكشف، بشرط أن يكون إخفاء الهوية حقيقيا وألا يستطيع المشغل حجب المسار انتقائيا.
يمكن أن يحمل تبادل الأقران بيانات صغيرة جدا عبر قناة خارجية، حتى بواسطة رمز استجابة سريع. لكن الشرط الصعب هو اتصال شبكة الشهود. إذا لم تتقاطع جماعتان قط، يمكن للسجل إبقاؤهما على فرعين مختلفين. توحيد صيغة الرسالة لا يصنع اللقاء الاجتماعي الذي ينقلها.
استعادة الحساب لا ينبغي أن تمحو ذاكرة الشاهد
يستطيع العميل رفض تاريخ بديل لأنه يحتفظ بنقطة تحقق من الماضي. إذا فُقد رأس الشجرة الأخير أو التزامات المراقبة أو توقيعات الشهود في لحظة حساسة، فقد يقبل الجهاز المستعاد تاريخا جديدا من دون نقطة تصطدم به.
تتعامل البنية مع فقدان الحالة كخطر صريح. في Contact Monitoring تكون القيم الحديثة داخل نافذة المراقبة والمناطق التي لم تنتشر بين الأقران أكثر حساسية. وفي التدقيق الخارجي ترتبط الفترة الضعيفة بالتأخير المقبول للمدقق. جلسة ويب زائلة أو تبديل جهاز أو نسخة احتياطية ناقصة أو إعادة ضبط يفرضها مهاجم يمكن أن تقلل الضمان من دون تغيير خوارزمية التحقق.
يجب أن تحدد استعادة الحساب ما يستمر: آخر رأس مقبول، ومهام Monitor غير المنجزة، وتوقيعات الأطراف الخارجية، وأوقات المقارنة، وهوية إعداد السجل. عندما يتعذر إثبات الاستمرارية ينبغي تسجيل الفجوة وتطبيق سياسة استعادة محلية، لا معاملة الجهاز بصمت كأنه لم ير أي تاريخ.
يعتمد زمن الكشف على عدة حدود: أقصى قِدم مقبول للإجابة، وReasonable Monitoring Window، والتكرار الفعلي للعمل الخلفي، وفترة الفحص المجهول أو تبادل الأقران، وتأخير المدقق، وفعالية كشف انقسام المدير. وقد يحتاج المستخدم إلى البقاء متصلا مدة كافية. لا تصبح عبارة الكشف خلال زمن محدود قابلة للمساءلة إلا إذا قيست كل مدة وعُرف مالكها.
لذلك لا تكفي نسبة نجاح البراهين. ينبغي حفظ عمر نقطة التحقق لكل جهاز، وعمر شهادة المدقق، وفشل المقارنات، وتراكم مهام المراقبة، وأحداث استعادة الحالة، ورفض الإجابات القديمة، والزمن بين ظهور التعارض والقرار المحلي. قد تبقى لوحة التحقق خضراء بالكامل داخل فرع معزول.
الشفافية لا تلغي التحكم في الوصول
لا يستبدل Key Transparency النقل أو تسجيل الدخول أو قواعد التفويض. تستطيع الخدمة حصر البحث في جهات الاتصال، وتقييد المعدل، ومنع تعديل وسم لا يملكه المستخدم. يقدم السجل دليلا على تنفيذ عملية مسموحة، لكنه لا يمنح الإذن بنفسه.
يخلق Contact Monitoring التزاما يمتد عبر الزمن. قد يكون شخص مخولا للبحث عن وسم أمس ثم يفقد الصلاحية اليوم، لكنه لا يزال بحاجة إلى Monitor لإكمال التحقق الناتج عن مشاهدته السابقة. تطلب المسودة السماح بهذا الفحص. إغلاق جميع المسارات عند سحب الإذن قد يغلق الطريق الوحيد الذي يكشف إخفاء القيمة.
تختلف آثار الخصوصية. يعرف المدقق عدد التغييرات وترتيبها وتوقيتها التقريبي، من دون رؤية الأوسمة والقيم بصورتها الواضحة. يعرف المدير عادة الأوسمة والقيم والتاريخ وأنماط الاستعلام التي يعرفها المشغل. تحتاج القناة المجهولة إلى حماية بياناتها الوصفية، وقد يكشف تبادل الأقران علاقات أو لقاءات. لا يوجد شاهد بلا أثر معلوماتي.
لذلك ينبغي أن يحدد أي ترتيب مستقل نطاق الرؤية والاحتفاظ والربط ومحتوى التوقيع وتوزيع المفتاح وحد التأخير والاستبدال. الاستقلال ليس اسما تعاقديا بل سلوك تشغيلي قابل للفحص.
الهجرة يجب ألا تتقاعد معها الأدلة القديمة
ينبغي أن تستعد الأجهزة للتعامل مع سجلات متعددة لأن الانتقال إلى سجل جديد وسيلة تعاف مهمة بعد فشل السجل. في الهجرة التدريجية يجب إبقاء السجل القديم متاحا حتى ينهي المستخدمون الذين يبقون غير متصلين طويلا مراقبتهم. إيقافه مبكرا يحرمهم من اكتشاف بعض السلوك السابق.
في الهجرة الفورية يجب توزيع الحجم النهائي والجذر التجزئي للسجل القديم عبر قناة موثوقة حتى يغلق الجميع التاريخ عند نقطة واحدة. وفي نظام اتحادي يلزم اتفاق على السجل المسؤول عن كل هوية، وإلا نشأ الانقسام عند اختيار السلطة قبل فحص البرهان.
ويتطلب التقليم تمييزا آخر. قد تنتهي بيانات المستخدم أو تصبح غير قابلة للوصول، بينما تبقى بعض البيانات التشفيرية لازمة لإثبات الحالة المتبقية. يجب تنسيق الحذف والبرهنة من دون الادعاء أنهما قرار واحد.
دليل الانقسام لا يصدر أمرا نهائيا
عندما تتعارض رؤيتان قابلتان للتحقق يستطيع المستخدم حفظ دليل لا يمكن إنكاره على سوء سلوك السجل. لكن التطبيق يختار ما بعد ذلك: تحذير، أو تجميد تغيير المفتاح، أو إيقاف التسليم، أو طلب تحقق خارجي، أو عزل جهاز، أو إبقاء خدمة محدودة أثناء التحقيق.
تكلفة الإنذار الخاطئ وانتحال الهوية والانقطاع تختلف بين البيئات. على الآلية المشتركة أن تجعل التعارض قابلا للرؤية والنقل. ويبقى القرار النهائي لدى من يفهم السياق ويتحمل الضرر، على أن يكون مسجلا وقابلا للمراجعة والتراجع.
لا يكتمل اختبار النشر بمجرد نجاح البرهان في المختبر. يجب التحقق من أن المقارنات المستقلة تعمل فعلا، وأن الحالة تنجو من الاستعادة اليومية، وأن أدلة السجل القديم تبقى متاحة أثناء الهجرة، وأن المؤسسة تعرف من يملك حق إيقاف الاتصال. لا يصبح السجل شفافا إلا عندما يستطيع شهوده الالتقاء.
المصادر
- https://datatracker.ietf.org/doc/draft-ietf-keytrans-architecture/
- https://datatracker.ietf.org/doc/draft-ietf-keytrans-architecture/history/
- https://datatracker.ietf.org/doc/draft-ietf-keytrans-architecture/writeup/
- https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-architecture-09
- https://datatracker.ietf.org/doc/draft-ietf-keytrans-protocol/
- https://ietf-wg-keytrans.github.io/draft-arch/draft-ietf-keytrans-architecture.html
- https://www.rfc-editor.org/rfc/rfc6962.html
- https://www.rfc-editor.org/rfc/rfc9162.html
- https://www.rfc-editor.org/rfc/rfc9381.html
- https://www.rfc-editor.org/rfc/rfc9420.html
- https://www.rfc-editor.org/rfc/rfc9458.html
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
