مبادئ تصميم البروتوكولات الآمنة

يفترض تصميم البروتوكولات الآمنة وجود خصم يسيطر سيطرة كاملة على الشبكة. ويحدد نموذج Dolev-Yao (1983) أن الخصم يستطيع اعتراض أي رسالة أثناء نقلها وقراءتها وتأخيرها وإعادة تشغيلها وحذفها وتعديلها. كما يستطيع إنشاء رسائل لا يمكن تمييزها عن الرسائل الصادرة عن الأطراف الصادقة. ويمكنه تركيب رسائل جديدة من مكونات الرسائل المعروفة. لكنه لا يستطيع كسر البدائيات التشفيرية (فك التشفير من دون المفتاح أو تزوير التواقيع). والأهم أن قدرات الخصم الحسابية محدودة — فهو يعمل في زمن كثير الحدود — لكنه يسيطر على جميع قنوات الاتصال. ويعني أمان البروتوكول تحقيق أهداف المصادقة والسرية حتى في مواجهة هذا الخصم القوي، بالاعتماد فقط على الصعوبة الحسابية للبدائيات الأساسية.

استخلص Abadi وNeedham (1994) دروسًا عملية في تصميم البروتوكولات وحوّلاها إلى مجموعة من المبادئ. (1) يجب أن توضح كل رسالة معناها: ينبغي أن يكون تفسير الرسالة مكتفيًا بذاته، لا معتمدًا على السياق. (2) يجب التصريح صراحةً في البروتوكول بالشروط التي تتيح لأحد الأطراف اتخاذ إجراء. (3) إذا كانت هوية أحد الأطراف مهمة، فيجب التصريح عنها صراحةً في الرسالة. (4) يجب توضيح سبب استخدام التشفير: فالتشفير يوفر السرية، بينما يوفر التوقيع المصادقة؛ لذلك لا تستخدموا التشفير بديلًا عن التوقيع. (5) ينبغي تشفير الرسالة في طبقة البروتوكول التي تحتاج إلى سريتها. وقد منعت هذه المبادئ كثيرًا من عيوب NS-type.

تُعد هجمات إعادة التشغيل من أكثر الثغرات شيوعًا في البروتوكولات. وتضمن آليات الجِدّة أن الرسالة المستلمة أُنشئت حديثًا، لا أنها أُعيد تشغيلها من جلسة قديمة. وهناك نهجان: (1) Nonces (Number used ONCE) — أسلوب تحدٍّ واستجابة يرسل فيه المستقبل قيمة عشوائية ويتوقع إعادتها في الاستجابة. ويجب أن تتضمن الاستجابة nonce مشفَّرة أو موقَّعة، مما يمنع تسجيلًا قديمًا من اجتياز التحدي. (2) الطوابع الزمنية — يضمّن الطرفان الوقت الحالي؛ فتُرفض الرسالة ذات الطابع الزمني القديم. وتتطلب الطوابع الزمنية ساعات متزامنة (يسمح Kerberos بانحراف قدره 5 دقائق). وتُفضَّل Nonces عند عدم توفر مزامنة للساعة، بينما تبسط الطوابع الزمنية عملية التحقق عديم الحالة.

يؤدي استخدام مفتاح تشفيري واحد لأغراض متعددة إلى تفاعلات خطرة. فإذا استُخدم مفتاح K لكل من التشفير والمصادقة، فقد يمرر الخصم نصوصًا مشفَّرة صُممت خصيصًا إلى آلية المصادقة لاستخراج معلومات. ويتجنب TLS 1.3 ذلك بصرامة عبر HKDF-Expand-Label، باستخدام تسميات مميزة لكل مفتاح مشتق: "c hs traffic" (مصافحة العميل)، و"s hs traffic" (مصافحة الخادم)، و"c ap traffic" (تطبيق العميل). وحتى إذا اختُرق مفتاح المصافحة، تظل مفاتيح التطبيق المشتقة من فرع HKDF مختلف آمنة. ويجب أن تراجع تصميمات البروتوكولات كل مفتاح بحثًا عن مخاطر الاستخدام المتعدد، وأن تشتق مفاتيح منفصلة للأغراض المنفصلة.

يجب ربط بيانات اعتماد المصادقة بالجلسة المحددة التي تُستخدم فيها. ومن دون هذا الربط، يمكن إعادة استخدام بيانات اعتماد جرى الحصول عليها في جلسة ما ضمن جلسة أخرى. التقنيات: (1) تضمين معرّفات الجلسة في البيانات الموقّعة أو المحمية بـ MAC. (2) تضمين سجل تبادل DH في التوقيع (نهج STS). (3) استخدام مفتاح الجلسة المشتق عبر HKDF لإجراء MAC على الهوية (نهج SIGMA). رسالة Finished في TLS 1.3: MAC(server_finished_key, transcript_hash) — يغطي MAC سجل التبادل الكامل، ولذلك تفشل إعادة استخدام رسالة Finished من جلسة مختلفة. وهذا الربط هو ما يمنع الهجمات العابرة للجلسات التي وُجدت في الإصدارات المبكرة من Kerberos وNS.

يجب ألا تفصح البروتوكولات إلا عن الحد الأدنى من المعلومات اللازمة لوظيفتها. ويجب كشف الهويات فقط لمن يحتاج إليها. لا تُضمّن أرقام تسلسل الشهادات أو المعرّفات التي تتيح ربط الجلسات بالهويات، إلا عند الحاجة إليها. يشفّر TLS 1.3 شهادة الخادم، بخلاف TLS 1.2 حيث تكون الشهادة بنص واضح، مما يقلل المعلومات التي يحصل عليها المتنصت السلبي. يشفّر ESNI، أي SNI المشفّر، المعروف الآن باسم ECH، أي Client Hello المشفّر، إشارة اسم الخادم لإخفاء الخادم الذي يتصل به العميل. ويُعد الحد الأدنى من إفصاح المعلومات مبدأً في تصميم الرموز المميزة أيضًا: ينبغي أن تتضمن مطالبات JWT ما يلزم للتفويض فقط، لا سجلات الهوية الكاملة.

يمثل التفاوض على الإصدار سطحًا شائعًا للهجوم: إذ يحذف الخصم رسالة ClientHello أو يعدّلها لإجبار الطرفين على استخدام إصدار أقدم وأضعف من البروتوكول. وتشمل وسائل الدفاع: (1) التفاوض الموثّق على الإصدار — تضمين الإصدار المتفاوض عليه في سجل التبادل الموقّع، إذ تغطي رسالة Finished في TLS رسالة ClientHello بما في ذلك الإصدار. (2) مؤشرات خفض المستوى — يضع TLS 1.3 بايتات سحرية في ServerHello.Random عند خفض المستوى إلى TLS 1.2، مما يتيح للعميل اكتشاف ذلك. (3) منع عدم تحمّل الإصدارات — يجب على الخوادم رفض رسائل ClientHello المشوهة من دون الرجوع بصمت إلى إصدار أقدم. (4) SCSV — تشير TLS_FALLBACK_SCSV إلى الخادم بأن العميل يعيد المحاولة باستخدام إصدار أقل، مما يتيح للخادم رفض عمليات الرجوع غير المشروعة.

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

كثيرًا ما تفشل البروتوكولات المعقدة عند حدود آلة الحالات. فإذا كان انتقال الحالة غامضًا — ماذا يحدث إذا وصلت الرسالة 3 قبل الرسالة 2؟ وماذا يحدث إذا وصلت رسالة من نوع غير متوقع؟ — فقد تختلف التطبيقات، مما ينشئ حالات متناقضة يمكن للخصم استغلالها. يجب أن تحدد مواصفات البروتوكول: آلة الحالات الكاملة، بما في ذلك جميع الحالات والانتقالات الصالحة؛ والسلوك عند إدخال غير متوقع، سواء برفضه مع خطأ محدد أو بتجاهله بصمت؛ والمهلات الزمنية وحدود إعادة الإرسال؛ وتنظيف الجلسة. وقد عانى SSL/TLS تاريخيًا من اختلاف التطبيقات في آلات الحالات — إذ كان CVE-2014-0160 (Heartbleed) في جوهره فشلًا في آلة الحالات، حيث عولج طلب نبضة قلب في حالة لم تكن فيها الذاكرة محددة الحدود على نحو صحيح.

نادرًا ما تُستخدم بروتوكولات التشفير بمفردها. إذ ينشئ بروتوكول AKE مفتاح جلسة، ثم تستخدمه بروتوكولات طبقة التطبيق. وإذا صُمم بروتوكول AKE وبروتوكول التطبيق بصورة مستقلة من دون مراعاة قابلية التركيب، فقد تخل التفاعلات بينهما بالأمان. يوفر إطار قابلية التركيب الشاملة (UC) (Canetti, 2001) نموذجًا صارمًا لتركيب البروتوكولات: يكون البروتوكول آمنًا وفق UC إذا ظل آمنًا عند تركيبه بصورة اعتباطية مع بروتوكولات أخرى آمنة وفق UC. ويستهدف TLS 1.3 وSignal وNoise تحقيق أمان قابل للتركيب. وعمليًا، ينبغي استخدام ربط القناة، أي تصدير تجزئة سجل التبادل، لربط جلسة AKE بمصادقة التطبيق اللاحقة، ومنع تمرير بيانات الاعتماد بين الجلسات التي أنشأها بروتوكول AKE نفسه.

يكرر مصممو البروتوكولات ارتكاب الفئات نفسها من الأخطاء. (1) ابتكار التشفير الخاص: تنفيذ شفرات كتل أو دوال MAC أو اشتقاق مفاتيح مخصصة من دون مراجعة من الأقران. (2) الثقة الضمنية: افتراض مصدر الرسالة بناءً على سياق الشبكة بدلًا من الإثبات التشفيري. (3) الأمان الاختياري: جعل التشفير أو المصادقة قابلين للتهيئة، مما يؤدي حتمًا إلى خفض المستوى. (4) الرموز المميزة طويلة العمر من دون إبطال: إصدار JWTs أو مفاتيح جلسات ذات أعمار طويلة ومن دون آلية إبطال. (5) تجاهل قناة الأخطاء: يتيح عدم مصادقة رسائل الخطأ للخصم حقن أخطاء للتأثير في سلوك البروتوكول. (6) استخدام التشفير للمصادقة: فتشفير البيانات لا يصادق على مصدرها من دون MAC أو توقيع.

يطبق التصميم الآمن للبروتوكولات مبادئ راسخة: نموذج الخصم Dolev-Yao، أي الخصم المتحكم في الشبكة؛ ومبادئ Abadi-Needham، أي الهوية الصريحة والرسائل المكتفية ذاتيًا؛ وتحقيق الجِدّة باستخدام nonces أو الطوابع الزمنية؛ وفصل المفاتيح باستخدام HKDF مع تسميات مختلفة؛ وربط بيانات اعتماد المصادقة بالجلسة؛ والحد الأدنى من إفصاح المعلومات؛ ومنع خفض المستوى عبر مصادقة سجل التبادل؛ وعدم القابلية للتلاعب باستخدام AEAD وتجزئة سجل التبادل؛ وآلات حالات واضحة مع معالجة محددة للأخطاء؛ وقابلية التركيب عبر براهين الأمان وفق نموذج UC. وتمثل انتهاكات هذه المبادئ مصدرًا لكل ثغرة تشفيرية معروفة تقريبًا على مستوى البروتوكول.