← العودة إلى المقالاتتقنيJuly 29, 20267 د قراءةCopy article

استشارة: اكتشاف حاسم في نموذج الحوسبة غير القابلة للتمسك PIE

يزيل النموذج قدرة المشغل على فك تشفير أي شيء بمجرد انتهاء المهمة. لا يزال الجهاز يشفّر إلى مفتاح عام غير موثَّق منشورًا بواسطة المكوّن الوحيد الذي يحدده النموذج على أنه غير موثوق.

Developed by Robert E. Beckner III (Merlin) | rbeckner.com

لقد كنت أبني أنظمة ل25 سنوات، وأحب بناء أشياء مصممة عمداً ومبنية بشكل عملي، تحمل فقط ما يكفي من المتجه لتحقيق وزنها.في هذا النهج، كان تقليل ما أُخزنه من بيانات المستخدم دائمًا منطقيًا بالنسبة لي، لأسباب تتجاوز البسيط. سيادة بياناتهم مهمة. تحتها شيء أبسط: الأشياء تنتمي حيث تنتمي. معظم ما أبنيه هو معالجة، وبنية معالجة لا تعمل كأية شيء آخر. الاحتفاظ بسجل لم يحتاجه أبدًا هو متجه لا يحقق أي شيء. معاملة ذلك كتحسين، بدلاً من كتمرين امتثال، هو ما يحافظ على التصميم صادقًا — ونظام مبني بهذه الطريقة يميل إلى البقاء في وضع جيد مع التنظيم بمفرده، لأن هناك القليل جدًا منه المتبقي للرقابة.لذلك عندما جاء إعلان Mary كاماشو عبر خلاصة الأخبار على X، قرأت هيكليتها كما أقرأ هيكليتي. لقد نشرت جوهرها في السجل العام تحت رخصة Creative Commons، على مستوى التفاصيل الذي يحتاجه المهندس لإعادة بنائها، وكانت صريحة حول الفن السابق الذي تستند إليه.أثناء العمل عبر التسلسل، وضعت كيانًا عدائيًا داخل الخادم وتابعت ما يمكنه الوصول إليه. كان يمكنه تجاوز العامل.تقريبًا كل العمل الذي تبعه حدث كحديث صوتي — عبر 30 ملاحظات صوتية، تفكير بصوت عالٍ واختبار القلق من زوايا مختلفة حتى أو استسلم أو انهار.

ما لاحظته: الجهاز يُشفّر لمن يكتب سجل المطالبة أولًا#

يُحدد الكشف ترتيب العمليات مباشرةً. يطالب العامل بالوظيفة وينشر مفتاحه، ثم فقط يُشفّر الجهاز:

العامل → التنسيق: استبيان وطلب الوظيفة (كتابة مرة واحدة، الفائز الأول)، نشر مفتاح العامل العام.
الجهاز ← التنسيق: استبيان، استرجاع مفتاح العامل العام، اشتقاق السر المشترك، تشفير الحمولة.
— §2.1, تدفق البيانات (لكل وظيفة)

جانب الجهاز من ذلك الاتفاق محدد بدقة متساوية:

الجهاز، عند معرفة مفتاح العامل العام، يُجري تبادل X25519 الخاص به وتغليف ML-KEM ضد مفتاح العامل، مُنتجًا مساهمته العامة الخاصة (مفتاح عام X25519 ‖ نص ML-KEM) والسر المشترك.— §4.2, الربط بدورة حياة العامل

عند التعلم. عبر صفحات 19 لا توجد توقيع على مفتاح العامل المؤقت، ولا شهادة، ولا شهادة التحقق التي يقيمها الجهاز، ولا سر مشترك مسبق. الغياب مقصود ومقدّم كقوة: النموذج يقيّد فك التشفير دون أي وثيقة تحقق، أو اقتباس TPM، أو قطعة تشغيل مقاسة، ولا يحتفظ بسر العامل المسبق التزويد.لذلك يُشفّر الجهاز حموله إلى أي مفتاح عام موجود في سجل المطالبة، دون وسيلة لتمييز مفتاح عامل شرعي من أي شخص آخر. أي طرف قادر على كتابة مطالبة أولًا يصبح الطرف الذي يُشفّر إليه الجهاز، وتُفكّ شيفرة الحمولة الموثّقة في أيديهم.

Diagram source

flowchart TB
    subgraph BEFORE["قبل: كما نشر"]
        direction TB
        A2{"من يدّعي أولاً؟"} -->|عامل حقيقي| A3["مفتاح أصلي"]
        A2 -->|أي كاتب آخر| A4["مفتاح مهاجم"]
        A3 --> A5["الجهاز يُشفّر إليه"]
        A4 --> A5
        A5 --> A6["حامل المفتاح يمكنه القراءة"]
    end
    subgraph AFTER["بعد: مفتاح موقع"]
        direction TB
        B2{"هل التوقيع صالح؟"} -->|نعم| B3["مفتاح عامل موثَّق"]
        B2 -->|لا| B4["رفض، أعد المحاولة"]
        B3 --> B5["فقط العامل الحقيقي يقرأ"]
    end
    A6 ~~~ B2

Copy sourceالجدية تأتي من ما يحمله النموذج. هذه المعمارية موجودة للاحتفاظ بالبيانات التي يرفض الناس قراءتها، وتنجح في النصف الأصعب من هذه المشكلة: لا يمكن فك تشفير عمل مكتمل من قبل أي شخص، بما في ذلك المشغل. الفجوة تكمن في الخطوة الواحدة التي يجب على الجهاز فيها تحديد من يتحدث إليه.

التشفير صحيح والمقدمة غير مُوثّقة#

المهاجم لا يكسر أي شيء. X25519 و ML-KEM-768 يعملان تماماً كما هو محدد. يقدّم المهاجم مفتاحاً ويصبح طرفاً شرعياً في الاتفاقية.هذا هو اتفاق مفتاح غير مُوثّق، وضعفها هو أقدم نتيجة في المجال. يثبت Diffie-Hellman البسيط لا يُوثّق أحداً ويُسقط على طرف يستبدل مفتاحه العام. تُورث آليات تغليف المفتاح هذه الخاصية، ولهذا السبب يضع RFC 9180 أصالة مفتاح المستلم خارج نطاقه ويُفترض أن التطبيق المحيط يحدده عبر شهادات، أو دليل مفاتيح، أو التحقق خارج الخط. هذا النموذج هو التطبيق المحيط، والقناة التي يستخدمها لتوزيع مفتاح المستلم هي المكوّن الذي يصفه نموذج الثقة الخاص به بأنه غير موثوق.يتوقع الإفشاء هجومًا مجاورًا ويغلقه:

المطالبة هي كتابة-مرة/الفائز-الأول لذا لا يمكن لعامل لاحق أن يسرق تبادل مفتاح وظيفة.— §6, تنفيذ مرجعي

هذا المنطق صحيح والآلية تفعل ما تقوله. يغطي أحد حالتين متماثلتين.

تهديد	يُعالَج بمطالبة الكتابة مرة واحدة
يقوم عامل ثانٍ بكتابة مطالبة موجودة مسبقًا	نعم — يتم رفض الكتابة
يكتب طرف غير مخول المطالبة أولًا	لا — الكتابة الأولى تفوز

الفوز الأول هو سباق. يضمن القاعدة أن الفائز يحتفظ بالوظيفة ولا يذكر من هو الفائز.هناك ادعاء آخر يستحق الاقتباس، لأن الاكتشاف يتناقض معه:

لا يحمل أي وسيط (بوابة، تنسيق، تخزين، مراقب) أبدًا كمية كافية من المواد المفتاحية لاستنتاج أي سر. يكتسب مهاجم يسيطر على التنسيق أو التخزين فقط كتلًا غير شفافة ومفاتيح عامة.— §4.3، مفاتيح مستقلة في كل اتجاه

الجملة الأولى دقيقة. الثانية تصف مهاجمًا يقرأ. يضع مهاجم يكتب مفتاحًا عامًا مختارًا في سجل المطالبة قبل أن يستعلم الجهاز، ويصبح استنتاج السر الشرعي غير ضروري لطرف يمكنه الترتيب ليكون الطرف المقابل. من يدير محتويات ذلك السجل يدير من يمكنه قراءة الحمولة، مما يجعل طبقة التنسيق مكونًا موثوقًا للسرية — الشيء الوحيد الذي يقول §3 أنه لا ينبغي لأي مكون بخلاف الجهاز والعامل أن يكون أبدًا.حد صادق للمطالبة: هذا لا يعني أن أي شخص على الإنترنت المفتوح يمكنه قراءة هذه البيانات اليوم. في نشر حقيقي، تتواجد القدرة على كتابة المطالبات خلف شبكة سحابية وبيانات الاعتماد، وتصف الإفصاح بوابة مصادقة على مسار الجهاز. المشكلة الدقيقة هي أن السرية الآن تعتمد على ذلك الحافة، بينما الوعد المركزي للمعمارية هو أنه يظل دون ثقة المكونات بين الجهاز والعامل.

خاصيتان تصميميتان يضاعفان العواقب#

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

الفجوة هي الظل الذي يحدده أفضل قرار للنموذج#

تفصل البنية بين البيانات التي قد يحملها المشغل بشكل مشروع والبيانات التي لا يجب أن يحملها أبدًا. بيانات الاتصال هي من هو الشخص وكيفية الوصول إليه. البيانات الموثقة هي ما يكشفون عنه عن أنفسهم. تسجل الأنظمة التقليدية كلاهما في قاعدة بيانات واحدة، وهو ما يحول جدول الحساب إلى سجل لحياة شخص ما الخاصة. الجواب الهيكلي هو سطر واحد: احتفظ بالاتصال، لا تستطيع احتواء الموثق.إزالة المنسق المركزي يخدم ذلك مباشرة. المكوّن الذي يخصص الوظائف للعمال يتعلم بالضرورة من يفعل ماذا، وهذه المعرفة هي الأصل الدقيق الذي يرفض النموذج حيازته. إزالة ذلك أيضًا أزالت المكوّن الذي كان سيؤيد عادة هوية العامل، وكل مسار متبقٍ لتوثيق العامل تم رفضه بشكل مستقل، كلٌ لأسباب دفاعية.النتيجة هي تصميم يتعامل مع الحيازة بدقة حقيقية ويطبق التفكير في الحيازة عند النقطة الوحيدة التي يكون فيها شكل المشكلة هو المصادقة. يطلب نموذج الثقة ما يحمل كل مكوّن ويجيب بشكل صحيح. السؤال المطلوب هناك هو ما يمكن لكل مكوّن استبداله. هذه مشكلتان مستقلتان في الثقة، ولم يُحل أحدهما أبدًا الآخر.

يختتم توقيع على المفتاح العام المؤقت للموظف ذلك المفتاح#

يولد الموظف زوج المفاتيح المؤقتة عند بدء التشغيل تمامًا كما يفعل الآن. قبل نشر ذلك المفتاح في مطالبة، يتم توقيعه بمفتاح عامل طويل الأمد، نصفه العام يُرسل مع التطبيق. يتحقق الجهاز من التوقيع قبل اشتقاق أي شيء ويرفض المفتاح غير الموقّع أو غير الصالح. تم تحديد الاسترداد بالفعل، لأن إعادة المحاولة التي يقودها العميل مع مهمة جديدة واتفاق مفتاح جديد هو مسار الفشل القياسي للنموذج.الخاصية الحاسمة هي أن مفتاح التوقيع لا يفك تشفير أي شيء. إن اختراق مفتاح التوقيع للعميل يتيح انتحال هوية موظف مستقبلاً ولا يمنح أي قدرة على قراءة مهمة مكتملة واحدة، لأن مفاتيح كل مهمة تم تدميرها مع موظفيها. عدم الحيازة، خزانة المفاتيح الفارغة، وعدم إمكانية فك التشفير الرجعي جميعها تبقى سليمة. هذا ما يجعل هذا إكمالًا للتصميم.يبقى الموقّع بعيدًا عن أن يصبح المنسق الذي أزال التصميم. يحتاج فقط إلى إثبات أن مفتاحًا عامًا مؤقتًا معينًا ينتمي إلى موظف أطلقه العامل، ولا يحتاج أبدًا لمعرفة المهمة التي سيطالب بها ذلك الموظف. المراقب الحالي هو المنزل الطبيعي: يوفّر ويستخلص الموظفين، ولا يحمل بيانات مستخدم ولا مفاتيح، وبحسب التصميم لا يوجه أو يخصص المهام.تستحق إعادة التشغيل فحصًا، لأن موقّعًا لا يعرف المهمة لا يمكنه ربط توقيع بمعرف مهمة. يظل المهاجم الذي ينسخ مفتاح موظف موقع حقيقي إلى سجل مطالبة مختلف دون المفتاح الخاص المقابل، لذا يبقى الحمولة غير مقروءة. النتيجة هي مهمة لا يمكن لأحد معالجتها — رفض الخدمة، مع الحفاظ على السرية.تبقى ثلاث حدود، ويذكر الكشف جميعها: النص العادي موجود في ذاكرة الموظف أثناء تشغيل المهمة، تسرب توقيت المهمة بيانات وصفية، وبناء اشتقاق المفتاح معلم للتحسين من قبل المؤلف.

استشارة#

هذا الاكتشاف موجود لأن المعمارية وضعت في المجال العام. ما جعل التقييم المستقل ممكنًا هو النشر، ولهذا السبب ظهر الفجوة هنا بدلاً من تقرير حادثة. نسخة مملوكة من هذا النظام ستحمل نفس المشكلة دون أن يكون هناك من يصرح بذلك.أقدّر المساهمة، ويستحق النموذج التدقيق الذي دعا إليه. الموقف المركزي قائم، وهو الشكل الذي أريد أن تتبناه المزيد من الأنظمة، لأن معمارية لا تحتفظ أبدًا بالبيانات الموثوقة تحمل جزءًا من السطح التنظيمي لتلك التي تفعل ذلك.التوصية ضيقة: احقن مفتاح عام مؤقت للموظف قبل أن يشفّر الجهاز إليه. توقيع واحد، يتم التحقق منه على الجهاز، بتكلفة لا شيء يجعل النموذج يستحق التبني. كل ما سبق خرج من محادثة تحويل الصوت إلى نص عبر أكثر من 30 ملاحظات، تم التحقق منها مقابل الإفصاح المنشور بدلاً من أي ملخّص له. إذا تم التحقق من هذه النتائج على جانبهم، فهي مباشرة للتنفيذ.#privacy-architecture#cryptography#post-quantum#security#software-architecture#ai#data-protection#systems-design—Robert E. Beckner III (Merlin)متابعة القراءةالسابقActivate: أربع سنوات من البناء من أجل الناس الذين يطرقون الأبواب التاليQwen 3.8-27B على M1 Ultra: من 12.1 إلى 20.3 توك/ثانية بقياس كل شيء كيف تحول مكاسب الذكاء الاصطناعي إلى بنية تحتية متراكمةتقنيApril 3, 20267 د قراءة Benchmark-Driven Development: Beyond TDD for AI SystemsاكتشافSeptember 23, 202510 د قراءة Benchmark-Driven Development: A Framework for AI System ConfigurationتقنيSeptember 23, 202510 د قراءةمشاريع ذات صلةAIA - مستشار الذكاء الاصطناعيابتكار الذكاء الاصطناعي Sphinx Capitalالتقنية المالية