يمكن لـ AES-GCM حماية سرية الرسالة وكشف التغييرات غير المصرّح بها. لكنه لا يخبر المستلم، بمفرده، ما إذا كانت رسالة صحيحة من النواحي الأخرى قد عولجت بالفعل.
يسهل الخلط بين ثلاثة متطلبات: أزواج فريدة من المفتاح وnonce للتشفير، ومصادقة الرسالة وسياقها، ومعالجة إعادة الإرسال على مستوى البروتوكول. يمكن أن يساعد HKDF في اشتقاق المفاتيح، لكنه لا يستوفي المتطلبات الثلاثة تلقائيًا.
إعادة استخدام nonce وإعادة الإرسال حدثان مختلفان
| الحدث | ما الذي يحدث | الحماية المطلوبة |
|---|---|---|
| إعادة استخدام nonce أثناء التشفير | تُشفَّر نصوص صريحة مختلفة بمفتاح GCM وقيمة nonce نفسيهما | استراتيجية موثوقة لتخصيص المفتاح وnonce |
| العبث | يتغير النص المشفّر أو السياق المصادَق عليه | فك تشفير موثَّق والرفض عند فشل التحقق |
| إعادة الإرسال | تُسلَّم مجددًا رسالة مشفّرة كانت صحيحة سابقًا | حالة وقواعد تطبيق تتعرفان إلى الرسائل المكررة أو المتقادمة |
| تغيير الترتيب | تصل الرسائل الصحيحة بترتيب مختلف | ترتيب يحدده البروتوكول ومعالجة محدودة النطاق للوصول خارج الترتيب |
قد يظل للنص المشفّر المعاد إرساله وسم مصادقة صحيح، إذ لم يتغير شيء. لذلك من الخطأ القول إن كل نسخة مكررة تفشل تلقائيًا في مصادقة AES-GCM. يفصل RFC 5116 صراحة بين واجهة AEAD وخدمات منع إعادة الإرسال.
لماذا يجب ألّا يتكرر زوج المفتاح وnonce؟
لا يلزم أن تكون قيمة nonce في GCM سرية، لكنها يجب أن تستوفي متطلبات الفرادة لهذا المخطط تحت مفتاح معيّن. يشيع استخدام nonce بطول 96 بت، أو 12 بايت، لكن اختيار هذا الطول لا يضمن توليدها بطريقة صحيحة.
إعادة استخدام المفتاح وnonce نفسيهما لنصوص صريحة مختلفة تعيد استخدام تيار مفاتيح التشفير، مما يكشف علاقات بين النصوص الصريحة. ويمكن أن تقوّض الأصالة وتتيح التزوير أيضًا. الأثر خطير، لكن لا ينبغي وصفه بأنه يكشف تلقائيًا كل مفتاح قديم أو كل رسالة في الحساب. يعتمد النطاق المتأثر على المفتاح المعاد استخدامه والبروتوكول.
يعرّف NIST SP 800-38D GCM ومتطلباته. يجب أن تتبع التطبيقات حدود الاستدعاء وقواعد توليد nonce المنطبقة، لا قاعدة تقريبية مبسطة مثل «آمن حتى هذا العدد من الرسائل».
ما الذي يضيفه HKDF؟
يشتق HKDF، المحدد في RFC 5869، مادة مفاتيح من مادة سرية مدخلة باستخدام مرحلتي الاستخراج والتوسيع. ويمكن للبروتوكولات استخدام تسميات السياق ومدخلات متميزة لفصل مفاتيح الأغراض المختلفة.
HKDF حتمي. فإذا كرر عميل تعطل أو أُعيدت حالته إلى الوراء الحالة والمدخلات نفسيهما، فقد يشتق المخرج نفسه مجددًا. ولذلك فإن إضافة HKDF إلى تصميم لا تجعل إعادة استخدام nonce مستحيلة.
يمكن للمفاتيح الخاصة بكل رسالة تقليل مقدار المحتوى المحمي تحت مفتاح واحد، لكن التقدم الآمن للحالة وفصل المفاتيح وحذفها تظل أمورًا مهمة. استخدام قيمة nonce نفسها تحت مفاتيح مختلفة فعلًا ليس الإخفاق نفسه الذي يحدث عند تكرار زوج المفتاح وnonce؛ وعلى البروتوكول إثبات أن المفاتيح مختلفة حقًا.
الحماية من إعادة الإرسال من مسؤولية البروتوكول
قد يتتبع المستلم معرّفات الرسائل أو مواقع التسلسل أو حقب الجلسة أو مفاتيح آلية ratchet المستهلكة. ويجب مصادقة الحقول المعنية كي لا يستطيع مهاجم إعادة تسمية رسالة قديمة على أنها جديدة.
ثم يجب أن يقرر التطبيق ما الذي يعنيه التكرار. عرض فقاعة محادثة مكررة مزعج، أما تنفيذ الإجراء نفسه مرتين فقد يكون أشد خطورة. محاولات الشبكة المتكررة أمر طبيعي، لذا غالبًا ما تلزم معالجة لا يتغير أثرها عند تكرارها، إلى جانب الفحوص التشفيرية.
لا تشترط وصول كل رسالة صحيحة بترتيب صارم ما لم ينص البروتوكول على ذلك. فالعملاء على الهواتف يعيدون الاتصال والمحاولة ويتلقون رسائل متأخرة بانتظام. تميّز المعالجة الآمنة الرسالة المتأخرة المشروعة عن رسالة سبق استهلاكها أو ذات سياق خاطئ.
ما الذي ينبغي اختباره قبل الادعاء بتوفير الحماية؟
- أعد التشغيل بعد تخصيص nonce وقبل تسجيل الإرسال: هل يمكن أن يتكرر التخصيص؟
- استعد لقطة أقدم للحالة: هل يمكن أن تتراجع المفاتيح أو العدّادات أو سجلات إعادة الإرسال؟
- أرسل بالتزامن من عاملين أو جهازين: هل نطاقات المفتاح وnonce منفصلة بينهما؟
- سلّم الرسالة الصحيحة نفسها مرتين: هل يُنفَّذ إجراء التطبيق مرة واحدة؟
- غيّر معرّف جلسة أو ترويسة: هل السياق مربوط تشفيريًا؟
- سلّم رسائل صحيحة خارج الترتيب: هل تُعالَج التأخيرات المدعومة من دون قبول حالة متقادمة؟
ينبغي لواجهات API الخاصة بفك التشفير الموثَّق أن تعيد النص الصريح إلى التطبيق فقط عند نجاح التحقق. هذا متطلب للواجهة، وليس ادعاءً بأن أي تنفيذ لا يحسب أبدًا مخزنًا مؤقتًا للنص الصريح داخليًا.
قراءة ادعاءات Livara بدقة
تذكر وثائق الأمان في Livara AES-256-GCM وسلاسل لكل رسالة وسياق LVR1/LGS1. لا تثبت هذه اللبنات وحدها صحة التعافي من التعطل أو تخصيص nonce أو رفض إعادة الإرسال. تتطلب مثل هذه الادعاءات تفاصيل بروتوكول محددة الإصدار وأدلة اختبار.
يوزّع التصميم القوي كل مهمة بوضوح: اشتقاق المفاتيح ينشئ المفاتيح المقصودة، وAEAD يصادق على المحتوى والسياق، ومنطق البروتوكول الذي يحتفظ بالحالة يقرر ما إذا كانت رسالة صحيحة مقبولة الآن.
