Signing Twice Is Forever: State-Management Discipline for Stateful Hash-Based Signatures Under Operational Faults
تقيم هذه الورقة انضباطات إدارة الحالة للتوقيعات القائمة على الهاش ذات الحالة (XMSS وLMS) في ظل الأعطال التشغيلية، مبرهنةً على أن استراتيجيات الادعاء المعاملاتي هي الوحيدة التي تمنع إعادة استخدام المفتاح الكارثية، مع الكشف عن أن حماية استعادة لقطة الحالة تتطلب ركائز رتيبة خارجية، وأن التأجير المجمع هو الحل الآمن والمنخفض زمن الوصول الوحيد لـ LMS رغم العقوبات الكبيرة في الأداء في مكتبات البرمجيات غير المرقعة.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
في العالم الرقمي، هناك أسرار قيمة للغاية لدرجة أنه لا يمكن السماح باستخدامها أكثر من مرة واحدة. تخيل مفتاحاً رئيسياً يفتح باباً واحداً فقط؛ بمجرد فتح ذلك الباب، يجب تدمير المفتاح. إذا استُخدم المفتاح مرة ثانية، حتى عن طريق الخطأ، فإن النظام الأمني بأكمله ينهار، ويمكن لأي شخص يراقب العملية أن يزور مفاتيحه الخاصة لفتح أي باب يختاره. هذا هو الواقع بالنسبة لنوع محدد من التوقيعات الرقمية يسمى "التوقيع القائم على الهاش ذو الحالة" (stateful hash-based signature). هذه هي الأدوات التي تتجه إليها الحكومات وخبراء الأمن بينما يستعدون لمستقبل قد تكسر فيه الحواسيب الكمومية القوية أكثر طرق التشفير شيوعاً اليوم. وخلافاً للتوقيعات الرقمية الأخرى التي تعتمد على ألغاز رياضية معقدة، تعتمد هذه التوقيعات على الطبيعة البسيطة وغير القابلة للكسر لـ "دالة الهاش" (hash function)، وهي عملية تحول البيانات إلى بصمة فريدة. نقطة ضعفهم الوحيدة ليست خللاً في الرياضيات، بل خلل في كيفية إدارتهم: فإذا نسي النظام أي باب فتحه للتو وحاول استخدام نفس المفتاح مرة أخرى، ستضيع الحماية للأبد.
يكمن التحدي في تتبع هذا المفتاح أحادي الاستخدام عبر شبكة من الحواسيب التي قد تتعرض للانهيار، أو إعادة التشغيل، أو الاستعادة من النسخ الاحتياطية. تبحث دراسة جديدة أجراها الباحث المستقل "أربان شارما" (Arpan Sharma) في كيفية إدارة هذا التتبع بدقة دون ارتكاب أخطاء. تركز الدراسة على طريقتين معتمدتين، وهما XMSS وLMS، واللتان يتم فرض استخدامهما الآن لتوقيع البرمجيات والبرامج الثابتة (firmware) الحساسة. تطرح الدراسة سؤالاً عملياً: عندما يفشل نظام حاسوبي أو يعيد التشغيل، ما هي القواعد البرمجية التي تمنع النظام من إعادة استخدام مفتاح عن طريق الخطأ؟ ولإيجاد الإجابة، قام الباحثون ببناء خدمة توقيع محاكية تحاكي بيئة واقعية حيث تتشارك الحواسيب قاعدة بيانات واحدة. ثم أخضعوا هذا النظام لسلسلة من الاختبارات القاسية، بما في ذلك إنهاء عمليات الحاسوب بشكل مفاجئ، وتشغيل نسخ متعددة من النظام في وقت واحد، واستعادة النظام إلى لقطة (snapshot) قديمة من نسخة احتياطية، تماماً كما قد يفعل مدير النظام أثناء عملية الاستعادة.
وكشفت النتائج أن الطريقة الأكثر شيوعاً للتعامل مع هذه المفاتيح معيبة بشكل خطير. تستخدم العديد من الأنظمة نهجاً بسيطاً حيث يقرأ النظام رقم المفتاح الحالي، ثم يوقع رسالة، ثم يكتب الرقم الجديد مرة أخرى في قاعدة البيانات. يبدو هذا منطقياً، لكن الدراسة أظهرت أنه إذا تعطل الحاسوب في الجزء من الثانية الفاصل بين عملية التوقيع والحفظ، أو إذا حاول حاسبان التوقيع في نفس الوقت، يمكن للنظام بسهولة أن يفقد تتبعه ويعيد استخدام مفتاح ما. في هذه الاختبارات، أدت هذه الطريقة الشائعة إلى إعادة استخدام العشرات، وأحياناً المئات من المفاتيح في دورة تشغيل واحدة. ووجد الباحثون أن الطريقة الوحيدة لضمان السلامة ضد حالات الانهيار والتزامن هي استخدام انضباط "الحجز أولاً" (claim-first). في هذه الطريقة، يجب على النظام حجز رقم المفتاح التالي رسمياً في قاعدة البيانات قبل استخدامه لتوقيع أي شيء. وهذا يضمن أنه حتى لو تعطل الحاسوب فوراً بعد عملية الحجز، فسيتم تعليم المفتاح كـ "مستخدم"، ولن يحاول النظام استخدامه مرة أخرى أبداً.
ومع ذلك، فإن السلامة تأتي بتكلفة، وقد كشفت الدراسة عن اختلاف مفاجئ بين طريقتي التوقيع. بالنسبة لإحدى الطريقتين، XMSS، كان النهج الآمن لإدارة المفاتيح شبه مجاني من حيث السرعة، حيث لم يضف أي تأخير يُذكر إلى عملية التوقيع. أما بالنسبة للطريقة الأخرى، LMS، فقد كان الوضع أكثر تعقيداً. ففي نسخة المكتبة البرمجية المستخدمة في الدراسة، كانت الطريقة الآمنة بطيئة جداً لدرجة أنها غير قابلة للاستخدام عملياً. ففي كل مرة يحاول فيها النظام توقيع رسالة بعد إعادة التشغيل، كان عليه إعادة بناء هيكل شجري رقمي ضخم من الصفر، مما يستغرق مئات الملي ثانية لإجراء واحد فقط. وقد أبلغ الباحثون عن هذه المشكلة لمطوري البرمجيات، الذين أضافوا إصلاحاً في نسخة أحدث من المكتبة. سمح هذا الإصلاح للنظام بحفظ جزء من الهيكل الشجري حتى لا يضطر لإعادة بنائه في كل مرة. وبينما جعل هذا الطريقة الآمنة أسرع بكثير، إلا أنها لم تكن سريعة بما يكفي لتكون عملية للاستخدام عالي الكثافة.
خلصت الدراسة إلى أنه بالنسبة لطريقة LMS، فإن السبيل الوحيد لتكون آمناً وسريعاً في آن واحد هو استخدام نهج "التأجير بالدفعات" (batched leasing). فبدلاً من حجز مفتاح واحد في كل مرة، يقوم النظام بحجز كتلة مكونة من ستة عشر مفتاحاً دفعة واحدة، ثم يستخدم تلك المفاتوات في الذاكرة لفترة من الوقت قبل طلب كتلة أخرى. هذا النهج يوزع تكلفة إعادة بناء الشجرة المكلفة على العديد من التوقيعات، مما يجعل العملية سريعة بما يكفي للاستخدام في العالم الحقيقي مع بقائها آمنة. كما سلط البحث الضوء على حد جوهري لا يمكن لأي خدعة برمجية التغلب عليه: إذا تم استعادة النظام إلى نسخة احتياطية قديمة، فإن أي طريقة تخزن عداد المفاتيح داخل تلك النسخة ستفشل. ستتضمن النسخة الاحتياطية رقم مفتاح قديماً، وسيبدأ النظام في إعادة استخدام مفاتيح تم استخدامها بالفعل في الفترة ما بين النسخة الاحتياطية والانهيار. ولمنع ذلك، وجد الباحثون أنه يجب الاحتفاظ بالعداد في جهاز خارجي منفصل لا يمكن استعادته من نسخة احتياطية، مثل وحدة أمن الأجهزة (HSM) المتخصصة. وهذا يؤكد أن المتطلب العتادي لهذه التوقيعات المحددة ليس مجرد اقتراح، بل هو ضرورة هيكلية.
تقدم هذه النتالئ خارطة طريق واضحة للمهندسين الذين يبنون الجيل القادم من البرمجيات الآمنة. فهي تظهر أن الاعتماد على أنماط قواعد البيانات القياسية ليس كافياً، وأنه يجب اتباع قواعد محددة ومنضبطة لتجنب حالات الفشل الأمني الكارثية. فبالنسبة لنوع واحد من التوقيعات، الحل بسيط ورخيص. أما بالنسبة للنوع الآخر، فهو يتطلب استراتيجية محددة لحجز المفاتيح في دفعات، والأهم من ذلك، الاحتفاظ بالعداد الرئيسي خارج قاعدة البيانات الرئيسية للحماية من الانهيارات ولقطات النسخ الاحتياطي الحتمية. وبينما ينتقل العالم نحو الأمن المقاوم للحوسبة الكمومية، ستحدد هذه التفاصيل التشغيلية ما إذا كانت الأنظمة الجديدة ستظل آمنة أم ستنهار تحت وطأة نفسها.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.