إطار عمل Noise Protocol

يُعد Noise Protocol Framework (من إعداد Trevor Perrin عام 2016؛ والمراجعة الحالية من عام 2018) إطارًا لبناء بروتوكولات القنوات الآمنة باستخدام مجموعة صغيرة من البدائيات ولغة للأنماط. وبدلًا من تحديد بروتوكول واحد، يعرّف Noise مفردات لأنماط المصافحة تصف تسلسل عمليات DH وترتيبها. ويمكن إنشاء نسخة ملموسة من أي نمط Noise صالح باستخدام دوال DH (Curve25519 أو Curve448)، والتشفير (AESGCM أو ChaChaPoly)، والتجزئة (SHA-256 أو SHA-512 أو BLAKE2). ويُستخدم Noise في WireGuard وWhatsApp وSignal (بوصفه أساس X3DH) وLightning Network وI2P.

تتضمن كل مصافحة Noise طرفًا بادئًا (I) ومستجيبًا (R). وقد يمتلك كل طرف نوعين من المفاتيح: مفتاحًا ثابتًا (مفتاح هوية طويل الأمد، يُرمز إليه بـ s/S) ومفتاحًا مؤقتًا (يُنشأ جديدًا لكل جلسة، ويُرمز إليه بـ e/E). تشير الأحرف الصغيرة إلى مفتاح الطرف المحلي، بينما تشير الأحرف الكبيرة إلى المفتاح العام للطرف البعيد. يحدد نمط Noise المفاتيح التي تُرسل (كنص صريح أو بشكل مشفَّر) وعمليات DH التي تُجرى. فعلى سبيل المثال، تعني "e" إرسال مفتاحي العام المؤقت، بينما تعني "es" إجراء DH(my_ephemeral, remote_static). وتُدمج كل نتيجة DH في حالة التجزئة الجارية للمصافحة.

يتمثل جوهر Noise في SymmetricState، التي تحتفظ بثلاث قيم: ck (مفتاح التسلسل، ويُهيَّأ بتجزئة اسم البروتوكول)، وh (تجزئة المصافحة، أي تجزئة السجل الجارية)، وk (مفتاح التشفير الحالي). تُشغّل MixKey(input) الدالة HKDF(ck, input) لتحديث ck وk. وتُجزّئ MixHash(data) البيانات داخل h. وتشفّر EncryptAndHash(plaintext) النص الصريح باستخدام k، ثم تدمج النص المشفَّر في h. أما DecryptAndHash(ciphertext) فتفك تشفير النص المشفَّر وتدمجه في h. وتوفر تجزئة المصافحة h ربطًا بالسجل؛ فأي تعديل عدائي على أي رسالة يغيّر h، مما يؤدي إلى فشل فك التشفير. وفي نهاية المصافحة، تُنتج Split() حالتي CipherState منفصلتين للإرسال والاستقبال.

يُعد Noise_XX نمط المصادقة المتبادلة الأكثر استخدامًا. فهو يوفر مصادقة متبادلة بالمفاتيح الثابتة، إذ يُرسل المفتاحان الثابتان للطرفين أثناء المصافحة. النمط: (1) -> e (يرسل الطرف البادئ المفتاح العام المؤقت). (2) <- e, ee, s, es (يرسل المستجيب مفتاحًا مؤقتًا، ويجري DH(e,e) وDH(e,s_resp)، ثم يرسل المفتاح الثابت مشفَّرًا). (3) -> s, se (يرسل الطرف البادئ المفتاح الثابت مشفَّرًا، ويجري DH(s_init, e_resp)). بعد الخطوة 3، يكون الطرفان قد أدمجا ثلاث نتائج DH في مفتاح الجلسة: ee (السرية التامة إلى الأمام)، وes (مصادقة الخادم)، وse (مصادقة العميل). ويكون مفتاح الجلسة مستقلًا عن اختراق أي مفتاح طويل الأمد بعد انتهاء الجلسة.

يستخدم WireGuard نمطًا مشتقًا من Noise_IK، حيث يعرف الطرف البادئ المفتاح الثابت للمستجيب مسبقًا. (1) -> e, es, s, ss (يرسل الطرف البادئ مفتاحًا مؤقتًا، ويجري DH(e, S_resp)، ثم يرسل المفتاح الثابت مشفَّرًا، ويجري DH(s_init, S_resp)). (2) <- e, ee, se (يرسل المستجيب مفتاحًا مؤقتًا، ويجري DH(e_resp, e_init) وDH(e_resp, S_init)). يوفر نمط IK إخفاء هوية الطرف البادئ (إذ يُشفَّر مفتاحه الثابت باستخدام المفتاح الثابت للمستجيب في الخطوة 1) وإتمام المصافحة في رحلة ذهاب وإياب واحدة. ويضيف WireGuard طابعًا زمنيًا داخل حمولة الطرف البادئ المشفَّرة لمنع إعادة التشغيل. ويمنح ذلك WireGuard بساطته المميزة: مصافحة VPN كاملة في حزمتَي UDP.

تُعد تجزئة المصافحة h في نهاية مصافحة Noise تجزئةً للسجل تغطي كل رسالة مُرسلة. وتعمل هذه التجزئة كقيمة لربط القناة؛ إذ يحسب الطرفان قيمة h نفسها، ويمكن لأي بروتوكول تابع لجهة خارجية يريد الارتباط بجلسة Noise أن يضمّن h بوصفها nonce أو معرّف قناة. ويتيح ذلك المصادقة المركبة: إذ يمكن تنفيذ خطوة مصادقة بشهادة على نمط TLS بعد مصافحة Noise، مع ربط الشهادة بهذه الجلسة تحديدًا عبر h. ويمنع ربط القناة هجمات تمرير بيانات الاعتماد، التي تُعاد فيها مصادقة مأخوذة من جلسة إلى جلسة أخرى. وتوفر Split() قيمة h للتطبيق إلى جانب مفاتيح الجلسة.

يدعم Noise الأنماط المؤجلة في الحالات التي لا يعرف فيها الطرف البادئ المفتاح الثابت للمستجيب مسبقًا. ويشبه Noise_NX (لا يمتلك الطرف البادئ مفتاحًا ثابتًا؛ ويرسل المستجيب مفتاحه) بروتوكول TLS أحادي الاتجاه. ويتعامل Noise_XX مع الحالة التي يحتاج فيها الطرفان إلى تبادل المفاتيح. ويمكن لـ Noise_IK الرجوع إلى Noise_XXfallback إذا كان تخمين الطرف البادئ للمفتاح الثابت للمستجيب خاطئًا (مثلًا بعد تدوير مفتاح). ويتيح نمط الرجوع للمستجيب الإشارة إلى «لقد استخدمت المفتاح الخطأ؛ إليك مفتاحي العام الجديد» من دون كشف حدوث الرجوع للمراقبين الخارجيين، وبذلك يحافظ على إخفاء تفاصيل البروتوكول.

يستخدم WhatsApp وSignal نمط Noise_XX لإنشاء قنوات آمنة بين العملاء والخوادم. ويستخدم بروتوكول WhatsApp الثنائي Noise_XX مع Curve25519 وChaChaPoly وSHA-256. ويكون المفتاح الثابت للعميل هو مفتاح هويته الطويل الأمد. وبعد مصافحة Noise، تنفذ طبقة التطبيق مصادقة إضافية (تسجيل Signal والتحقق من رقم الهاتف). أما اتفاق X3DH (Extended Triple Diffie-Hellman) على المفتاح في Signal، فيجري أربع عمليات DH لإنشاء سر مشترك بين مستخدمين عبر تبادل رسائل غير متزامن؛ وهذا ليس نمطًا قياسيًا من أنماط Noise، لكنه يستخدم مفاهيم مشابهة لدمج DH. ثم يتولى Double Ratchet تشفير الرسائل المستمر.

يعالج Noise وTLS 1.3 المشكلة نفسها (تبادل المفاتيح الموثَّق) وفق فلسفتين مختلفتين. فـTLS 1.3 بروتوكول واحد يحدد مجموعات الشفرات وتنسيقات الشهادات (X.509) والامتدادات. وقد صُمم لمتصفحات الويب والخوادم، أي بوصفه بروتوكولًا واحدًا يناسب معظم الحالات. أما Noise فهو إطار عمل: لا يحدد تنسيقًا للشهادات، ولا PKI، ولا ربطًا بطبقة النقل. وهذا يجعل Noise أصغر (إذ يقل حجم تنفيذ Noise الكامل في WireGuard عن 400 سطر من التعليمات البرمجية) وأسهل في التحليل الرسمي، لكنه يتطلب من التطبيق إدارة الهوية بشكل منفصل. ويُفضَّل Noise في الأنظمة المغلقة (من التطبيق إلى الخادم، وVPN) حيث تكون PKI مبالغة غير ضرورية، بينما يُفضَّل TLS في الأنظمة المفتوحة (الويب) حيث يلزم التشغيل البيني للشهادات.

خضعت أنماط Noise لتحليل رسمي باستخدام نموذج الأمان eCK (extended Canetti-Krawczyk). وقد حلل Kobeissi وBhargavan وBlanchet بروتوكول Noise باستخدام Proverif، وتوصلوا إلى براهين للمصادقة وسرية المفاتيح لجميع أنماط Noise الأساسية الاثني عشر. وتفترض هذه البراهين صعوبة DH القياسية (Curve25519) وأمان دوال AEAD والتجزئة الأساسية. وتجعل الطبيعة التركيبية لـNoise (حيث تُدمج كل عملية DH تدريجيًا) تحليله أسهل من تحليل بروتوكولات معقدة شبيهة بـTLS تتضمن انتقالات حالة عديدة. وقد منحت عملية التحقق التشفيري لـNoise كلًا من WireGuard وWhatsApp ثقة عالية بأمان بروتوكوليهما قبل نشرهما.

من الأخطاء الشائعة في تنفيذ Noise: (1) الخلط بين الأنماط — يؤدي استخدام Noise_IK عندما لا يكون المفتاح الثابت للمستجيب موزعًا مسبقًا بشكل موثوق إلى عدم تطابق الهوية (فقد يشفّر الطرف البادئ بصمت إلى مفتاح خاطئ). (2) الحماية من إعادة التشغيل — يوفر Noise المصادقة، لكنه لا يوفر الحماية من إعادة تشغيل رسائل مرحلة Transport؛ لذلك يجب فرض nonce (عداد 64-بت)، ويجب أن يؤدي تجاوز العداد (بعد 2^64 رسالة) إلى إعادة إنشاء المفاتيح. (3) سلامة prologue — يجب أن يتضمن prologue الخاص بـNoise (وهو سلسلة بايتات تُدمج في h قبل بدء المصافحة) كل سياق البروتوكول (الإصدار وخيارات الخوارزميات) لمنع هجمات خفض المستوى. (4) إساءة استخدام PSK — يدعم Noise امتدادات PSK لدمج المفاتيح المشتركة مسبقًا؛ ويجب أن تتمتع PSKs بإنتروبيا عالية، لا أن تكون كلمات مرور للمستخدمين.

ماذا يعني الترميز "es" في نمط مصافحة Noise؟

Noise إطار عمل لبناء بروتوكولات تبادل مفاتيح موثَّقة باستخدام لغة أنماط لعمليات DH. تحتفظ SymmetricState بمفتاح التسلسل (ck) وتجزئة السجل (h) ومفتاح الشفرة (k)، وتحدّثها MixKey/MixHash. يوفر Noise_XX مصادقة متبادلة خلال 1.5 RTT، بينما يكتمل Noise_IK (المستخدم في WireGuard) خلال 1 RTT عند معرفة مفتاح المستجيب. وتعمل تجزئة المصافحة h على ربط القناة. وقد جرى التحقق الرسمي من Noise لجميع الأنماط الأساسية باستخدام Proverif. ويُفضَّل على TLS في بروتوكولات الأنظمة المغلقة (مثل WireGuard وWhatsApp) حيث لا تكون PKI ضرورية. ويتطلب التنفيذ الصحيح حماية من إعادة التشغيل، وسلامة prologue، وPSKs ذات إنتروبيا عالية.