التشفير الموثّق: AES-GCM وChaCha20-Poly1305

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

يجمع AES-GCM (نمط غالوا/العداد) مكوّنين: AES-CTR (نمط العداد) للتشفير، وGMAC (رمز مصادقة الرسائل غالوا) لضمان التكامل. ينشئ AES-CTR تدفق مفاتيح من خلال تشفير قيمة عداد وإجراء XOR بينها وبين النص الصريح — مما يجعل التشفير قابلًا للتنفيذ بالتوازي، بخلاف نمط CBC. ويحسب GMAC وسم مصادقة على النص المشفر وأي بيانات مرتبطة. وينتقل الوسم الناتج (بطول 128 بت) إلى جانب النص المشفر؛ ويؤدي أي تغيير في بت واحد إلى إبطال الوسم.

يتطلب AES-GCM استخدام nonce (رقم يُستخدم مرة واحدة)، ويكون عادةً بطول 96 بت (12 بايتًا). يجب أن يكون nonce فريدًا لكل عملية تشفير منفردة باستخدام المفتاح نفسه؛ ولا يلزم أن يكون سريًا، لكن يجب ألا يتكرر مطلقًا. إن إعادة استخدام nonce في AES-GCM كارثية: فإذا شُفّرت رسالتان بالمفتاح وnonce نفسيهما، يمكن للمهاجم إجراء XOR للنصين المشفرين لإلغاء keystream، ما قد يتيح له استعادة النصين الصريحين. تُسمى هذه الثغرة أحيانًا «إساءة استخدام nonce»، وقد تسببت في هجمات حقيقية لاستعادة المفاتيح.

عند إعادة استخدام nonces الخاصة بـ AES-GCM، يستطيع المهاجم حساب C1 XOR C2 = P1 XOR P2 (أي XOR للنصين الصريحين)، لأن keystream نفسه استُخدم لكليهما. بالإضافة إلى ذلك، تتيح إعادة استخدام nonce استعادة مفتاح المصادقة H، ما يعني أن المهاجم يستطيع تزوير authentication tags صالحة لرسائل عشوائية، وبذلك يكسر السرية والسلامة تمامًا. تعرضت أنظمة مثل Sony PS3 لهذا الهجوم تحديدًا. وتتمثل الحماية في استخدام nonces عشوائية (تُولَّد باستخدام CSPRNG) أو عدّاد حتمي لا يُعاد ضبطه مطلقًا.

يُعد ChaCha20-Poly1305 خوارزمية AEAD الأخرى المفروضة في TLS 1.3. أما ChaCha20 فهو Stream Cipher صممه Daniel Bernstein، ويولّد keystream باستخدام عمليات add-rotate-XOR (ARX)، من دون جداول بحث، وبزمن ثابت تمامًا، وبسرعة عالية للغاية على وحدات المعالجة المركزية التي لا تتضمن تسريعًا عتاديًا لـ AES. وPoly1305 هو MAC يُستخدم مرة واحدة (message authentication code) لحساب authentication tag على النص المشفر. ويوفران معًا مستوى أمان مكافئًا لـ AES-GCM، لكنهما أسرع بكثير على الأجهزة المحمولة وأجهزة IoT.

تتضمن معالجات x86 وARM64 الحديثة المستخدمة في أجهزة سطح المكتب والخوادم تعليمات عتادية AES-NI تجعل AES-GCM سريعًا للغاية. لكن العديد من معالجات الأجهزة المحمولة وأجهزة IoT تفتقر إلى AES-NI، ما يجعل AES-GCM البرمجي بطيئًا نسبيًا. صُمم ChaCha20-Poly1305 ليكون سريعًا عند تشغيله برمجيًا باستخدام عمليات حسابية بسيطة، وبذلك يوفر للأجهزة المحمولة أداءً مشابهًا من دون تسريع عتادي. أضافت Google خوارزمية ChaCha20-Poly1305 إلى TLS كبديل خصيصًا لأجهزة Android، وأصبحت الآن cipher suite أساسية في TLS 1.3.

يشير الحرفان «AD» في AEAD إلى Associated Data، وهي بيانات وصفية ذات نص صريح تتم مصادقتها، لكنها لا تُشفّر. يتيح ذلك مصادقة البيانات التي يجب أن تظل قابلة للقراءة، مثل ترويسات الحزم أو حقول نوع السجل، مع حمايتها من العبث. في TLS 1.3، تُضمَّن بايتات ترويسة السجل باعتبارها associated data في حساب AEAD. وإذا عدّل مهاجم الترويسة، مثل تغيير طول السجل، يفشل التحقق من authentication tag ويُنهى الاتصال.

قبل أن تصبح AEAD معيارًا معتمدًا، أوصى علماء التشفير باستخدام Encrypt-then-MAC (EtM): تشفير النص الصريح، ثم حساب MAC على النص المشفر. وهذا آمن، لكنه يتطلب عمليتين منفصلتين باستخدام مفتاحين منفصلين. أما مخططات AEAD مثل AES-GCM فتجمع العمليتين معًا باستخدام مفتاح واحد، ما يقلل تعقيد التنفيذ ويلغي فئة كاملة من هجمات padding oracle التي عانت منها طريقة MAC-then-Encrypt (MtE)، وهي الطريقة المستخدمة في إصدارات TLS الأقدم (CBC + HMAC). ويتجنب TLS 1.3، عند استخدام AEAD، هذه المشكلات بالكامل.

كل من AES-128-GCM وAES-256-GCM معتمد من NIST ويُعد آمنًا ضد الحواسيب الكلاسيكية. يوفر AES-128 أمانًا بمستوى 128 بت مع أداء أسرع قليلًا، بينما يوفر AES-256 أمانًا بمستوى 256 بت، ما يمنح هامشًا أكبر في مواجهة التحليل التشفيري المستقبلي والتهديدات الكمية. بالنسبة إلى معظم التطبيقات حاليًا، يُعد AES-128-GCM كافيًا، لكن الأنظمة الحكومية المصنفة (NSA Suite B) تتطلب AES-256. يوفر TLS 1.3 الخوارزميتين، ويمكن للخوادم ترتيب أولوياتهما وفقًا لسياسة الأمان لديها.

عند فك تشفير نص مشفر باستخدام AEAD، يجب على المستقبل التحقق من authentication tag قبل فك التشفير. وتتمثل العملية في إعادة حساب tag المتوقعة من النص المشفر والمفتاح وnonce المستلمة؛ ثم مقارنتها بـ tag المستلمة باستخدام دالة مقارنة بزمن ثابت؛ ولا تتم متابعة فك التشفير إلا إذا تطابقتا. تُعد المقارنة بزمن ثابت أمرًا بالغ الأهمية، إذ إن إيقاف المقارنة عند أول بايت غير متطابق يتيح للمهاجم تنفيذ هجوم قناة جانبية يعتمد على التوقيت لتزوير tags صالحة بايتًا تلو الآخر. وتكون أي مكتبة AEAD تستخدم مقارنة تتوقف مبكرًا عرضةً للخطر.

تنتشر خوارزميات AEAD في الأمن الحديث: يستخدم TLS 1.3 AES-GCM وChaCha20-Poly1305 لتشفير جميع السجلات؛ ويستخدم WireGuard VPN خوارزمية ChaCha20-Poly1305 حصريًا؛ ويستخدم Signal Protocol هذه الخوارزمية لتشفير الرسائل؛ بينما يستخدم QUIC protocol، الذي يُعد أساس HTTP/3، خوارزمية AES-GCM. وعندما ترى cipher suite مثل TLS_AES_256_GCM_SHA384، يشير SHA384 إلى دالة تجزئة HKDF المستخدمة لاشتقاق المفاتيح، وليس إلى آلية السلامة؛ إذ تتولى GCM tag ضمان السلامة.

اختبر مدى فهمك لمفاهيم CompTIA Security+ (SY0-701) التي تناولها هذا الدرس.

تعلمت في هذا الدرس أن خوارزميات AEAD توفر السرية والسلامة في الوقت نفسه عبر authentication tag تكشف أي تعديل في النص المشفر، وأن إعادة استخدام nonce في AES-GCM كارثية، إذ تتيح استعادة keystream وتزوير مفتاح المصادقة؛ لذلك يجب أن تكون nonces فريدة لكل عملية تشفير، وأن ChaCha20-Poly1305 هو البديل الفعال من حيث الأداء لـ AES-GCM على الأجهزة التي تفتقر إلى تسريع AES العتادي. في الدرس التالي، سنستكشف دوال اشتقاق المفاتيح المستخدمة لتأمين كلمات المرور.