التشفير في الشبكات
في الفصلين الأولين رأينا أنّ أمنَ الشبكات مسألةٌ متعدّدة الأوجه. ومن بين التهديدات (threats) الرئيسة التي يجب التصدّي لها أنّ البيانات المارّة عبر الشبكة عرضةٌ للقراءة أو للتعديل على يد مهاجم (attacker). أمّا التقنيةُ التأسيسية التي تُعالَج بها هذه التهديدات فهي التشفير (cryptography). ولهذا نبدأ دراستنا للمقاربات التقنية لأمن الشبكات بنظرةٍ عامّة على التشفير.
ونُقدّم مفاهيمَ الأمن المستنِدة إلى التشفير خطوةً خطوة. أمّا الخطوة الأولى فهي خوارزمياتُ التشفير — الشيفرات (ciphers) ودوالّ التجزئة التشفيرية (cryptographic hashes) — التي يتناولها هذا الفصل. وهذه الخوارزميات ليست حلولًا بحدّ ذاتها، بل توفّر لبناتٍ (building blocks) يمكن منها بناء حلّ. فمثلًا تُشرَك خوارزمياتُ التشفير بمعاملاتٍ تُسمّى مفاتيح (keys)، ويكون توزيعُ المفاتيح (key distribution) تحدّيًا نتناوله في الفصل التالي.
وبعد أن تتوفّر لدينا مجموعةٌ من خوارزميات التشفير وطريقةٌ لتوزيع المفاتيح، نصبح قادرين على بناء بروتوكولاتٍ (protocols) تتيح اتصالًا آمنًا بين المشاركين. وتتناول الفصولُ اللاحقة عدةَ بروتوكولاتٍ من هذا النوع، وتنتهي بوصف أنظمةٍ كاملةٍ تستعمل هذه البروتوكولات.
3.1 مبادئ الشيفرات
يحوّل التشفيرُ رسالةً بطريقةٍ تجعلها غير مفهومةٍ لأيّ طرفٍ لا يعرف سرَّ عكس هذا التحويل. يطبّق المرسِل دالةَ التشفير (encryption) على رسالة النصّ الصريح (plaintext) الأصلية، فتُنتَج رسالة مشفَّرة (ciphertext) تُرسَل عبر الشبكة، كما هو مبيَّن في الشكل 2. ويطبّق المستقبِل دالةَ فكّ التشفير (decryption) — وهي معكوسةُ دالة التشفير — لاستعادة النصّ الصريح الأصلي. أمّا النصّ المشفَّر الذي يُنقَل عبر الشبكة فهو غير مفهومٍ لأيّ متنصّت (eavesdropper)، بافتراض أنّ المتنصّت لا يملك الوسائلَ التي تمكّنه من تنفيذ دالة فكّ التشفير. أمّا التحويلُ الذي تمثّله دالةُ التشفير ودالّةُ فكّ التشفير المقابلةُ لها فيُسمّى شيفرة (cipher).
الشكل 2. التشفير وفكّ التشفير بمفتاحٍ سرّي.
وكما أشرنا في الفصل السابق، فقد اقتُرِح مبدأُ التصميم المفتوح (open design) لتقنيات الأمان منذ عام 1975 على الأقلّ. لكنّ للتشفير تاريخًا أطول بكثير من ذلك، إذ يعود إلى آلاف السنين. فقد صرّح أوغست كِرخوفس (Auguste Kerckhoffs)، وهو أحدُ أبرز علماء التشفير في القرن التاسع عشر، عام 1883 بأنّ تصاميمَ أنظمة التشفير نفسها ينبغي ألّا تكون سرّية، بل ينبغي أن تُشرَك بمعامل مفتاح (key) يسهل تغييره؛ فلا ينبغي ألّا يكون سريًّا إلّا المفتاح وحده. وهذا أيضًا يتبع مبدأَ تقليص الأسرار الوارد في الفصل 2.
أحدُ أسباب التصميم المفتوح هو أنّه إن اعتمدتَ على إبقاء الشيفرة سرّية، فلا بدّ من الانصراف عن الشيفرة (لا المفاتيح وحدها) حين تعتقد أنّها لم تعد سرّية. وهذا يعني احتمالَ تغيّر الشيفرة كثيرًا، وهو أمرٌ مشكلٌ لأنّ تطويرَ شيفرةٍ جديدة (وإثباتَ أمنها) يتطلّب جهدًا كبيرًا. وفي عصر ما قبل الحواسيب كانت الشيفراتُ تُنفَّذ غالبًا بأجهزةٍ متخصّصةٍ مثل آلة إنجما (Enigma)؛ وهذه لا يمكن استبدالُها بسهولة، لكنّ المفاتيح فيها كانت تتغيّر كثيرًا. أمّا خوارزمياتُ اليوم، فرغم أنّها مُنفَّذةٌ في برمجيات، فإنّها نتاجُ عملياتٍ طويلةٍ من التطوير والاختبار والتحليل والتوحيد القياسي؛ وكلُّ هذا يجعل استبدالَ الخوارزميات مكلفًا.
ولأنّ خوارزميات التشفير مكلفةٌ في الاستبدال، لكنّها تُكتشف أحيانًا بعد سنواتٍ من الاستخدام على أنّ لها ثغراتٍ (vulnerabilities)، فإنّها تُعامَل عادةً بوصفها وحداتٍ قابلةً للتبديل (pluggable) ضمن حلولِ الأمن الشاملة التي يتناولها كلٌّ من الفصول التالية. وفي حالاتٍ كثيرةٍ تكون الخوارزميةُ مُعاملًا قابلًا للاختيار في تلك الحلول، ما يعني أنّ النظامَ ككلٍّ لا يصبح متقادمًا لمجرّد أنّ إحدى وحدات التشفير فيه بحاجةٍ إلى الإهمال.
ومن أفضل السبل للتأكّد من أنّ شيفرةٍ ما آمنة هو استخدامها مدّةً طويلة — فكلّما بقيت سليمةً فترةً أطول، زاد احتمالُ أنّها آمنة. وكما في الأمن على العموم، فإنّ إثباتَ أنّ خوارزميةٍ تشفيرية لا يمكن كسرها هدفٌ سلبيٌّ نوعًا ما، ولذلك يصعب إنجازه بثقةٍ تامّة. ويمكننا أحيانًا إثباتُ أنّ كسر شيفرةٍ ما يصعب بقدر صعوبة حلّ مسألةٍ رياضيةٍ مدروسةٍ جيّدًا، مثل تحليل الأعداد الكبيرة إلى عواملها. وحتّى عندئذٍ قد تكون هناك مشكلاتٌ في التنفيذ لا تكشفها إلا مراجعةُ من يفحص الخوارزمية ويستعملها. وفي حالاتٍ كثيرةٍ لا بدّ لنا من الاعتماد على مجرّد أنّ أحدًا لم يعثر بعد على طريقةٍ عمليةٍ لكسر الشيفرة. ولحسن الحظّ فإنّ هناك الكثيرين ممن يحاولون كسرَ الشيفرات، ويجعلون نجاحَهم معروفًا على نطاقٍ واسع.
وتُضفي المفاتيحُ كمعاملاتٍ على الشيفرة ما هو في الحقيقة عائلةً ضخمةً جدًّا من الشيفرات؛ فبتبديل المفتاح ننتقل إلى شيفرةٍ أخرى في العائلة. ومن الشائع تحديدُ مقدار البيانات التي يمكن لـ محلّل التشفير (cryptanalyst — كاسر الشيفرات) الوصولُ إليها قبل تغيّر المفتاح. وهذا يمنح المهاجمَ قدرةً أقلّ على كسر الشيفرة، لأسبابٍ سنناقشها أدناه. كما أنّه يحدّ من الضرر الذي يلحق إذا كُسرت الشيفرة.
المتطلّبُ الأساسي لخوارزمية التشفير هو أنّها تحوّل النصَّ الصريح إلى نصٍّ مشفَّر بطريقةٍ لا تجعل سوى المستقبِل المقصود — حاملَ مفتاح فكّ التشفير — قادرًا على استعادة النصّ الصريح. أي أنّ الرسائلَ المشفَّرة لا يستطيع أن يقرأها من لا يملك المفتاح. وحين نقول «لا يمكن قراءتها» فسنقوم بافتراضاتٍ ما بشأن القدرات الحاسوبية والزمن المتاحين للمهاجم؛ وسنعود إلى هذا بعد قليل.
ومن المهمّ إدراكُ أنّه حين يستلم مهاجمٌ محتمل جزءًا من النصّ المشفَّر، فقد تكون بين يديه معلوماتٌ أكثر من مجرّد النصّ المشفَّر نفسه. فمثلًا قد يعرف أنّ النصّ الصريح كُتب بالإنجليزية، وهذا يعني أنّ الحرف e يرد فيه أكثرَ من أيّ حرفٍ آخر؛ ويمكن توقّع تكرار كثيرٍ من الحروف الأخرى ومجموعاتِ الحروف الشائعة أيضًا. ومع الشيفرات البسيطة يمكن لهذه المعلومات أن تيسّر كثيرًا مسألةَ تحديد المفتاح. وعلى نحوٍ مشابه قد يعرف المهاجم شيئًا عن المحتويات المحتملة للرسالة. فمثلًا من المرجَّح أن ترد الكلمة "login" في بداية جلسةِ دخولٍ عن بُعد، وأن تَرِد ترويساتٌ شائعة في بداية رسائل HTTP. وقد يتيح ذلك تنفيذَ هجومٍ بالنصّ الصريح المعروف (known plaintext attack)، الذي فرصةُ نجاحه أعلى بكثير من هجومٍ بالنصّ المشفَّر وحده (ciphertext only attack). وأفضلُ من ذلك هجومٌ بالنصّ الصريح المُختار (chosen plaintext attack)، وقد يُمكَّن من تغذية المرسِل بمعلوماتٍ تعرف أنّه مرجَّحٌ سينقلها.
ولذلك فإنّ أفضلَ الخوارزميات التشفيرية تمنع المهاجمَ من استنتاج المفتاح حتّى حين يعرف النصَّ الصريح والنصَّ المشفَّر معًا. وفي الحالة المثلى لا يملك المهاجمُ خيارًا سوى تجريب جميع المفاتيح الممكنة — بحثًا شاملًا، أي بحث «القوة الغاشمة» (brute-force). وإذا كانت المفاتيحُ بطول n بت، فإنّ للمفتاح 2n قيمةً ممكنة (يمكن أن يكون كلٌّ من البتات الـ n إمّا صفرًا وإمّا واحدًا). وقد يكون المهاجمُ محظوظًا إلى حدٍّ أن يجرّب القيمة الصحيحة فورًا، أو محظورًا إلى حدٍّ أن يجرّب كلَّ قيمةٍ خاطئة قبل أن يجرّب قيمةَ المفتاح الصحيحة، بعد أن يكون قد جرّب جميع القيم الـ 2n الممكنة؛ ومتوسّطُ عدد المحاولات لاكتشاف القيمة الصحيحة يقع في منتصف هذين الطرفين،
ويمكن جعلُ ذلك غير عمليٍّ حسابيًّا باختيار فضاءِ مفاتيحَ كبيرٍ بما يكفي وجعلِ عملية التحقّق من مفتاحٍ ما مكلفةً بصورةٍ معقولة. والصعوبةُ في ذلك أنّ سرعات الحوسبة تستمرّ في الزيادة، فتصير الحساباتُ التي كانت غير عمليةٍ في الماضي عمليّةً الآن. إضافةً إلى ذلك يسهل توازي هذه عمليات البحث الشاملة، ما يعني أنّ المهاجم يستطيع استعمالَ معالجاتٍ رسوميةٍ عامّة الغرض (GPGPUs) أو آلاتٍ أخرى تعمل على التوازي لتسريع الهجوم.
ويتبيّن أنّ إنشاءَ شيفراتٍ تشفيرية لا تُكسَر إلّا بالقوة الغاشمة ليس بالأمر الهيّن. فمثلًا كانت خوارزميةُ DES الأصلية (معيارُ تشفير البيانات، data encryption standard) تملك مفتاحًا بطول 56 بت فقط؛ وحين اتّضح أنّ 56 بت صغيرةٌ جدًّا، قُدِّم DES الثلاثي (triple DES) الذي يستعمل ثلاثَ جولاتٍ من DES، لكلٍّ منها مفتاحُها. وقد يبدو أنّ هذا قد رفع حجمَ المفتاح إلى 168 بت ()، لكنّ بنيةَ DES الثلاثي ذات الجولات الثلاث تجعل المهاجمَ الذي يملك جزءًا من النصّ المشفَّر والنصّ الصريح المقابلَ له مضطرًّا إلى البحث في فضاءِ مفاتيحَ بحجم 112 بت فقط. ويعتمد ذلك على ما يُسمّى «هجوم اللقاء في المنتصف» (meet-in-the-middle attack). والتفاصيلُ هنا ليست مهمّة، لكنّها توضّح لماذا تحتاج الخوارزمياتُ التشفيرية إلى تصميمٍ دقيق وتقييمٍ من خبراء حتى لا تضمّ نقاطَ ضعفٍ مفاجئة.
ويميل أمنُ الشبكات إلى التركيز على أمن البيانات وهي تمرّ عبر الشبكة — أي البيانات التي لا تكون معرّضةً للخطر إلّا لفتراتٍ قصيرةٍ جدًّا. لكنّنا على العموم ينبغي أن نأخذ في الحسبان كذلك احتمالَ أن تُلتقط البيانات لتحليلها لاحقًا، أو أن تُحفَظ بعضُ البيانات في أرشيفاتٍ لعشرات السنين. ويؤيّد هذا الأمرَ أكثرَ من قبل المطالبةَ بحجمِ مفتاحٍ سخيٍ استعدادًا للتقدّم الحاسوبي المستقبلي. غير أنّنا نحتاج أيضًا إلى مراعاة أنّ المفاتيحَ الأكبر تميل إلى جعل التشفير وفكّ التشفير أبطأ.
3.1.1 الشيفرات الكتليّة
معظمُ الشيفرات المستعملة اليوم هي شيفراتٌ كتليّة (block ciphers)؛ فهي معرَّفةٌ بأنّها تأخذ كمدخل كتلةً من النصّ الصريح ذات حجمٍ ثابتٍ معيَّن، وغالبًا 128 بت. واستعمالُ شيفرةٍ كتليّة لتشفير كلّ كتلةٍ على حدة — وهو ما يُعرف بتشفير وضع الكتاب الإلكتروني (electronic codebook, ECB mode) — يضعف الأمرَ من أنّ قيمةَ كتلةٍ صريحةٍ معيّنة ستنتج دائمًا الكتلةَ المشفَّرةَ ذاتها (طالما بقي المفتاح ثابتًا). ومن ثمّ فإنّ قيمَ الكتل المتكرّرة في النصّ الصريح يمكن التعرّفُ عليها بصفتها كذلك في النصّ المشفَّر، ممّا يجعل كسرَ الشيفرة على محلّل التشفير أسهلَ بكثير.
ولمنع ذلك تُضاف إلى الشيفرات الكتليّة دائمًا تحسيناتٌ تجعل النصّ المشفَّر للكتلة يتغيّر بحسب السياق. وتُسمّى السبلُ التي يمكن بها تحسينُ الشيفرة الكتليّة أنماط تشغيل (modes of operation). ومن نمط تشغيلٍ شائع سلسلةُ كتل الشيفرة (cipher block chaining, CBC)، وفيه تُعرَض (XOR) كلُّ كتلةٍ من النصّ الصريح مع النصّ المشفَّر للكتلة السابقة قبل تشفيرها. والنتيجةُ أنّ النصّ المشفَّر لكلّ كتلةٍ يعتمد جزئيًّا على الكتل السابقة (أي على سياقها). ولأنّ الكتلةَ الصريحة الأولى لا تسبقها كتلة، فإنّها تُعرَض مع عددٍ عشوائي. وهذا العددُ العشوائي، الذي يُسمّى متجه التهيئة (initialization vector, IV)، يُرفَق مع سلسلةِ كتل النصّ المشفَّر كي يمكن فكّ تشفير الكتلة المشفَّرة الأولى. ويوضّح الشكل 3 هذا النمط. أمّا نمطُ تشغيلٍ آخر فهو وضع العدّاد (counter mode)، وفيه تُدمج قيمٌ متتاليةٌ لعدّادٍ ما (مثل 1، 2، 3، ) في تشفير كتلِ النصّ الصريح المتتالية.
أمّا حجمُ الكتلة، مثل حجم المفتاح، فهو مقايضةٌ في التصميم. فقد استُعملت كتلٌ بحجم 64 بت لسنواتٍ طويلة، لكنّها — مع ازدياد سرعات الحواسيب والشبكات وانخفاض تكاليف التخزين — أصبحت معرّضةً لنوعٍ من الهجمات يقوم على مسألة عيد الميلاد (birthday problem) (أي احتمالُ أن يكون عيدُ ميلاد شخصين ضمن مجموعةٍ حجمها n متطابقًا، وهو احتمالٌ مرتفعٌ على نحوٍ مفاجئ). وإذا تمكّن المهاجمُ من إبقاء جلسةٍ مشفَّرة مفتوحةً مدةً كافيةٍ ليتلقّى كتلتين متطابقتين بحجم 64 بت، فإنه يحصل على معلوماتٍ نافعةٍ عن النصّ الصريح الذي أنتج هاتين الكتلتين. وكان هذا معروفًا منذ زمنٍ طويلٍ بوصفه مسألةً نظريّة، لكنّ استغلالَه أُثبِت عام 2016، ممّا أدّى إلى إهمال الكتل بحجم 64 بت.
وتستلزم الشيفراتُ الكتليّة حشوَّ الرسائل حتى حدود الكتلة التالية، وهو ما يهدّر شيئًا من عرض نطاق الشبكة، ولذلك فإنّ للكتل المفرطة في الحجم كلفة. ولهذا السبب استقرّت معظمُ الشيفرات اليوم على كتلٍ بحجم 128 بت. وتتوفّر بعضُ التفاصيل عن كيفية إثبات أنّ هجمات عيد الميلاد تُشكّل مشكلةً في موقع "Sweet32".
قراءات إضافية
Sweet32. هجمات عيد الميلاد على شيفراتٍ كتليّة بحجم 64 بت في TLS وOpenVPN.
3.2 شيفرات المفاتيح السرّية
في شيفرة المفاتيح السرّية (secret-key cipher) يتشارك الطرفان في الاتصال المفتاحَ نفسه.[1] وبعبارةٍ أخرى، إذا شُفِّرت رسالةٌ بمفتاحٍ معيَّن فإنّ المفتاحَ نفسه هو المطلوب لفكّ تشفيرها. ولو كانت الشيفرةُ المبيَّنة في الشكل 2 شيفرةَ مفاتيحٍ سرّية، لكان مفتاحا التشفير وفكّ التشفير متطابقين. وتُعرف شيفراتُ المفاتيح السرّية أيضًا بشيفرات المفاتيح المتماثلة (symmetric-key ciphers) لأنّ السرّ يتشارك فيه الطرفان. وسننظر لاحقًا إلى البديل، وهو شيفراتُ المفاتيح العامة. (وتُعرف شيفراتُ المفاتيح العامة أيضًا بشيفرات المفاتيح غير المتماثلة (asymmetric-key ciphers)، إذ سنرى قريبًا أنّ الطرفين يستعملان مفاتيحَ مختلفة.)
وقد أصدر المعهدُ الوطنيّ الأمريكيّ للمعايير والتقنية (U.S. National Institute of Standards and Technology, NIST) معاييرَ لسلسلةٍ من شيفرات المفاتيح السرّية. وكان معيارُ تشفير البيانات (Data Encryption Standard, DES) أولها، وقد صمد لعقودٍ قليلةٍ قبل أن يُهمَل.
وتحتوي مفاتيحُ DES على 56 بتًّا مستقلّة (رغم أنّها تحوي 64 بت إجمالًا؛ فآخر بت في كلّ بايت هي بتُّ التكافؤ). وكما أشرنا أعلاه، فأنت تحتاج في المتوسط إلى البحث في نصف فضاء الـ 256 مفتاحًا ممكنًا للعثور على المفتاح الصحيح، أي ما يعادل 255 = 3.6 × 1016 مفتاحًا. قد يبدو ذلك عددًا كبيرًا، لكنّه بحلول أواخر تسعينيات القرن الماضي كان من الممكن أصلًا استرجاعُ مفتاح DES خلال ساعاتٍ قليلة. وعليه حدّث NIST معيارَ DES عام 1999 ليشير إلى أنّ DES ينبغي ألّا يُستخدم إلّا في الأنظمة القديمة (legacy). ومن المهمّ أنّ DES لم يُثبَت قطّ أنّه معرّضٌ لهجومٍ سوى القوة الغاشمة.
واستُبدل DES أوّلًا بـ DES الثلاثي (Triple DES, 3DES). ويملك مفتاحُ 3DES ما مقداره 168 (= 3 × 56) بتًّا مستقلّة. وكما أشرنا أعلاه فإنّ الكلفةَ الحاسوبية لشنّ هجومٍ بالقوة الغاشمة لم تكن — على النحو المتوقَّع — كلفةَ البحث في فضاءِ مفاتيحَ بحجم 2168 بت، بل بحثًا في فضاء مفاتيحٍ بحجم 2112 بت بسبب هجوم «اللقاء في المنتصف». وفي الوقت نفسه ظلت الكلفةُ الحاسوبية لتنفيذ التشفير وفكّ التشفير أعلى بثلاث مراتٍ ممّا هي عليه في DES المفرد. وقد أدّى ذلك في النهاية إلى عمليّةِ استبدال DES بخوارزمياتٍ أحدث.
وأصبح 3DES الآن مهجورًا لصالح معيار التشفير المتقدّم (Advanced Encryption Standard, AES) الذي أصدره NIST. وقد كانت الشيفرةُ التي يقوم عليها AES (مع تعديلاتٍ طفيفة) تُسمّى أصلًا Rijndael (تُنطق تقريبًا مثل «Rhine dahl») استنادًا إلى اسمَي مخترعيها، وهما Daemen وRijmen. ويدعم AES أطوالَ مفاتيحَ قدرها 128 أو 192 أو 256 بت، في حين يبلغ طولُ الكتلة 128 بت. ويسمح AES بتنفيذاتٍ سريعةٍ في البرمجيات والعتاد معًا، وهو أكثرُ كفاءةً قليلًا من DES الثلاثي. ولا يحتاج إلى ذاكرةٍ كبيرةٍ على الإطلاق، ما يجعله مناسبًا للأجهزة الطرفية المحمولة الصغيرة.
ولن نُعمق النظرَ في تفاصيل شيفرات المفاتيح السرّية، لأنّها فعلًا مجالُ خبراء التشفير المختصّين. ويصاغ خبيرُ الأمن بروس شنير (Bruce Schneier) الأمرَ هكذا:
يستطيع أيّ شخص، من أكثر الهواة جهلًا إلى أفضل علماء التشفير، أن ينشئ خوارزميةً لا يستطيع كسرَها بنفسه. والأمرُ ليس صعبًا حتى ذلك الحدّ. إنّ الصعب هو إنشاء خوارزميةٍ لا يستطيع كسرَها أحدٌ غيرك، حتّى بعد سنواتٍ من التحليل. والطريقةُ الوحيدة لإثبات ذلك هي تعريض الخوارزمية لسنواتٍ من التحليل على يد أفضل علماء التشفير في العالم.
3.3 شيفرات المفاتيح العامة
والبديلُ عن شيفرات المفاتيح السرّية هو شيفراتُ المفاتيح العامة. فبدلًا من مفتاحٍ واحدٍ يتشاركه طرفان، تستعمل شيفرةُ المفاتيح العامة زوجًا من المفاتيح المترابطة، مفتاحًا للتشفير وآخر مختلفًا لفكّ التشفير. و«يملك» هذا الزوجَ من المفاتيحَ طرفٌ واحدٌ فقط. فيحتفظ المالكُ بمفتاحٍ واحدٍ من الزوج سرًّا، وهو المفتاح الخاصّ (private key). ويجعل المالكُ المفتاحَ الثاني عامًّا؛ وهو ما يُسمّى المفتاح العام (public key). ومن البديهيّ ألّا يكون من الممكن استنتاجُ المفتاح الخاصّ من المفتاح العام.
ويستطيع أيّ شخصٍ الحصولَ على المفتاح العام ثمّ استعمالَه لتشفير رسالةٍ قبل إرسالها إلى مالك المفاتيح. ولا يملك المالكُ وحده المفتاحَ الخاصَّ اللازم لفكّ تشفير تلك الرسالة. ويوضّح الشكل 4 هذا السيناريو.
الشكل 4. التشفير بالمفتاح العام.
ولأنّ الأمرَ غير بديهيٍّ إلى حدٍّ ما، فإنّنا نؤكّد أنّ مفتاحَ التشفير العام لا فائدةَ منه في فكّ تشفير رسالة — إذ لا يمكنك حتّى فكّ تشفير رسالةٍ شفّرتها بنفسك ما لم تكن تملك مفتاحَ فكّ التشفير الخاصّ. وإذا نظرنا إلى المفاتيح على أنّها تحدّد قناةَ اتصالٍ بين المشاركين، فإنّ اختلافًا مهمًّا بين شيفرات المفاتيح العامة وشيفرات المفاتيح السرّية يكمن في بنية (طوبولوجيا) هذه القنوات. فمفتاحُ شيفرةِ المفاتيح السرّية يوفّر قناةً ثنائيةَ الاتجاه بين طرفين — إذ يحمل كلُّ طرفٍ المفتاحَ نفسه (المتماثل)، ويستطيع أيٌّ منهما تشفيرَ الرسائل أو فكّ تشفيرها في أيّ اتجاه. أمّا زوجُ المفاتيح العامة/الخاصّ، على النقيض، فيوفّر قناةً أحاديةَ الاتجاه ومتعدّدةَ الأطراف نحو طرفٍ واحد: من كلّ من يملك المفتاح العام إلى المالك الوحيد للمفتاح الخاصّ، كما هو مبيَّن في الشكل 4.
ولا تُستعمل شيفراتُ المفاتيح العامة للتشفير فحسب، بل أيضًا للمصادقة (authentication). وتتمثّل طريقةُ عمل ذلك في أنّ المفتاح الخاصّ يمكن استعمالُه مع خوارزمية التشفير لتشفير الرسائل بحيث لا يمكن بعدها فكّ تشفيرها إلّا باستعمال المفتاح العام. ومن البديهيّ أنّ هذه الخاصية لا تفيد في السرّية، لأنّ أيّ شخصٍ يملك المفتاح العام يستطيع فكّ تشفير تلك الرسالة. لكنّ هذه الخاصية مفيدةٌ للمصادقة، إذ تبلّغ مستقبِلَ تلك الرسالة أنّه لم يكن ثمّة من أنشأها إلّا مالكُ المفاتيح (رهنَ افتراضاتٍ سنتناولها لاحقًا). ويوضّح ذلك الشكل 5.
ومن الواضح من الشكل أنّ أيّ شخصٍ يملك المفتاح العام يستطيع فكّ تشفير الرسالة المشفَّرة، وأنّه — إذا افترضنا أنّ نتيجةَ فكّ التشفير تطابق النتيجةَ المتوقَّعة — يمكن الاستنتاجُ أنّ المفتاح الخاصّ هو ما استُعمل لإجراء التشفير. أمّا كيفيةُ استغلال هذه العملية بالضبط لتوفير المصادقة فهي موضوعُ فصلٍ لاحق.
وللتلخيص يمكن استعمالُ شيفرات المفاتيح العامة لأغراض المصادقة وأيضًا لدعم الاتصالات السرّية عبر التشفير. وفي الحالة الأخيرة تُستعمل غالبًا لتهيئة (bootstrap) الاتصالات السرّية. فبدلًا من تشفير غالبية الرسائل المتبادلة بين المشاركين، تُستعمل شيفراتُ المفاتيح العامة لتوزيع المفاتيح السرّية (المتماثلة) بشكلٍ سرّي، تاركةً ما تبقّى من السرّية لشيفرات المفاتيح السرّية. والمفتاحُ المتماثل الذي يُرسَل عبر هذه القناة السرّية يُسمّى مفتاح الجلسة (session key). وتُشمل أسبابُ هذه المقاربة ذات المرحلتين كفاءةَ شيفرات المفاتيح السرّية الأعلى، والحاجةَ إلى تغيير مفاتيح التشفير بوتيرةٍ معقولةٍ كما وصفنا سابقًا.
الشكل 5. المصادقة باستعمال المفاتيح العامة.
وللتشفير بالمفاتيح العامة تاريخٌ مثيرٌ للاهتمام. فقد نُشر مفهومُ شيفرات المفاتيح العامة أوّلَ مرّة عام 1976 على يد ديفي وهيلمان. غير أنّ وثائقَ ظهرت لاحقًا تُثبت أنّ مجموعةَ الاتصالات والإلكترونيات الأمنية البريطانية (Britain's Communications-Electronics Security Group) قد اكتشفت شيفراتَ المفاتيح العامة بحلول عام 1970، ووكالةُ الأمن الوطنيّ الأمريكيّ (U.S. National Security Agency, NSA) تدّعي اكتشافَها في منتصف ستّينيات القرن الماضي.
وأشهرُ شيفرةٍ للمفاتيح العامة هي RSA، المسمّاةً بأسماء مخترعيها: ريفست وشامير وأدلمان. وتعتمد RSA على الكلفة الحاسوبية العالية لتحليل الأعداد الكبيرة إلى عواملها. أمّا مسألةُ إيجاد طريقةٍ كفؤة لتحليل الأعداد إلى عواملها فهي مسألةٌ عمل عليها الرياضيّون دون نجاحٍ منذ زمنٍ بعيدٍ قبل ظهور RSA عام 1978، ومقاومةُ RSA اللاحقة للتحليل التشفيري عزّزت الثقةَ في أمنها أكثرَ من ذلك. وللأسف تحتاج RSA إلى مفاتيحَ كبيرةٍ نسبيًّا، لا تقلّ عن 1024 بت، كي تكون آمنة. وهذا أكبرُ من حجم مفاتيح شيفرات المفاتيح السرّية، لأنّه أسرعُ كسرًا لمفتاح RSA الخاصّ عبر تحليل العدد الكبير الذي يستند إليه زوجُ المفاتيح منه عبر البحث الشامل في فضاء المفاتيح.
وشيفرةٌ أخرى للمفاتيح العامة هي ElGamal. ومثل RSA فإنّها تعتمد على مسألةٍ رياضية، وهي مسألةُ اللوغاريتم المتقطّع (discrete logarithm problem)، التي لم يُعثر لها على حلٍّ كفؤ، وتتطلّب مفاتيحَ لا يقلّ طولها عن 1024 بت. وهناك صيغةٌ من مسألة اللوغاريتم المتقطّع تنشأ عندما يكون المدخلُ منحنىً بيضاويًّا (elliptic curve)، ويُظنّ أنّ حسابَها أصعبُ من ذلك؛ وتُسمّى المخطّطاتُ التشفيرية المبنيةُ على هذه المسألة التشفيرَ بالمنحنيات البيضاوية (elliptic curve cryptography).
وللأسف فإنّ شيفراتَ المفاتيح العامة أبطأُ من شيفرات المفاتيح السرّية بدرجاتِ رتبةٍ عدّة. وعليه تُستعمل شيفراتُ المفاتيح السرّية في الغالبية العظمى من عمليات التشفير، فيما تُحجز شيفراتُ المفاتيح العامة لاستعمالها في المصادقة وإنشاء مفاتيح الجلسات.
3.4 مصادقة الرسائل
لا يوفّر التشفيرُ وحده سلامةَ البيانات. فمثلًا يكفي تعديلُ رسالةٍ مشفَّرة تعديلًا عشوائيًّا لتتحوّل إلى شيءٍ يفكّ تشفيرُه إلى نصٍّ صريحٍ يبدو صحيحًا، وعندئذٍ لا يستطيع المستقبِل اكتشافَ العبث. ولا يوفّر التشفيرُ وحده المصادقةَ أيضًا. وبمعنًى ما السلامةُ والمصادقةُ متلازمتان جوهريًّا. فلا فائدة تقريبًا من القول إنّ رسالةً جاءت من مشاركٍ معيَّن إذا كان محتوىُ الرسالة قد عُدِّل بعد أن أنشأه ذلك المشارك.
ورمزُ مصادقة الرسالة (message authentication code) هو قيمةٌ تُدرَج في رسالةٍ مُرسَلة، ويمكن استعمالُها للتحقّق في آنٍ واحد من أصالة الرسالة وسلامة بياناتها. وسنرى لاحقًا كيف يمكن استعمالُ هذه الرموز في البروتوكولات. أمّا الآن فنركّز على الخوارزميات القادرة على توليد رموز المصادقة والتحقّق منها.
وعند تخزين البيانات أو نقلها، من المتّعارف عليه استعمالُ رموزٍ لكشف الأخطاء أو تصحيحها. وهذه قطعٌ من المعلومات تُضاف إلى كائنِ بياناتٍ مخزَّن أو منقول، ليكتشف المستقبِل متى تعرّضت البيانات لتعديلٍ غير مقصودٍ ناتجٍ عن أخطاء البتات. فعلى الأقراص المدمجة (CDs) والأقراص الرقمية (DVDs) مثلًا تُستعمل رموزُ تصحيح الأخطاء للتعامل مع تلف البيانات الناجم عن الخدوش أو الغبار. وينطبق المفهومُ المماثل على رموز المصادقة، مع تحدٍّ إضافيّ هو أنّ العبثَ بالرسالة من المحتمل أن يكون قد نُفِّذ عمدًا على يد شخصٍ يريد ألّا يُكتشف. ولدعم المصادقة يتضمّن الرمزُ نوعًا من الإثبات على أنّ من أنشأه يعرف سرًّا لا يعرفه إلّا المرسِل المزعومُ للرسالة؛ فمثلًا قد يكون السرُّ مفتاحًا، وقد يكون الإثباتُ قيمةً مشفَّرة باستعمال ذلك المفتاح. وهناك تبادلُ اعتماديةٍ بين طريقة توليد الرمز وكيف يُستعمل كإثباتٍ على معرفة السرّ. ويناقش ما يلي عدةَ توليفاتٍ قابلةً للتطبيق.
ولتبسيط الأمر، لنفترض أوّلًا أنّ الرسالةَ الأصلية لا يلزم أن تكون سرّية — أي أنّ الرسالةَ المُرسَلة ستتألّف من النصّ الصريح للرسالة الأصلية إضافةً إلى شيفرةٍ إضافيّة تدعم المصادقة. وسننظر لاحقًا في الحالة التي تُرغَب فيها السرّية أيضًا.
ومن لبنات مصادقة الرسائل الشائعة دالةُ تجزئةٍ تشفيرية (cryptographic hash function). وتُعامَل خوارزمياتُ التجزئة التشفيرية بوصفها معارفَ عامّة، كما هي الحال مع خوارزميات الشيفرات. ودالةُ التجزئة التشفيرية هي دالةٌ تُخرج معلوماتٍ كافيةً عن رسالةٍ تكشف أيَّ عبثٍ بها. فكما تكشف قيمةُ التحقّق (checksum) أو شيفرةُ كشف الأخطاء عن أخطاء البتات التي يسبّبها الضجيجُ في الروابط أو الخدوشُ على الأقراص، فإنّ التجزئةَ التشفيرية مصمَّمةٌ لكشف العبث المتعمَّد بالرسائل من قِبل خصم. وتُسمّى القيمةُ التي تُخرجها بصمةَ الرسالة (message digest)، وهي، مثل قيمة التحقّق الاعتيادية، تُلحَق بالرسالة. ولكلّ البصماتِ التي تنتجها دالةُ تجزئةٍ معيّنة عددُ البتات نفسه مهما كان طولُ الرسالة الأصلية. ولأنّ فضاءَ رسائل الإدخال الممكنة أكبر من فضاءِ بصمات الرسائل الممكنة، فستوجد رسائلُ إدخالٍ مختلفةٌ كثيرةٌ تنتج البصمةَ ذاتها، مثل التصادمات (collisions) في جدول التجزئة. ومن الخصائصِ المهمّة لدوالّ التجزئة التشفيرية أنّ مثل هذه التصادمات لا يمكن إنتاجُها عمدًا تحت سيطرة المهاجم. وسنرى سببَ ذلك بعد قليل.
ويمكن إنشاءُ رمز مصادقة الرسالة بتشفير بصمة الرسالة باستعمال مفتاحٍ ما. وقد يكون ذلك المفتاحُ هو المفتاحَ الخاصَّ لشيفرةٍ غير متماثلة لا يعرفه إلّا المرسِل، أو قد يكون مفتاحًا سرًّا لشيفرةٍ متماثلة اتّفق عليه المرسِلُ والمستقبِلُ بطريقةٍ أخرى. وعند استلام الرسالة يحسب المستقبِلُ بصمةً للجزء الخاصّ بالنصّ الصريح من الرسالة ويقارنُها ببصمة الرسالة بعد فكّ التشفير. فإن تطابقتا استنتج المستقبِلُ أنّ الرسالة تعود فعلًا إلى مرسِلها المزعوم (لأنّها لا بدّ أن تكون شُفِّرت بالمفتاح الصحيح) وأنّها لم تُعبَّث بها.
ولنفترض أنّ خصمًا اعترض الرسالةَ في طريقها إلى المستقبِل وحاول تعديلَ الرسالة المنقولة بطريقةٍ ما. فإنّ بصمةَ هذه الرسالة المُفسَدة ستختلف (بدرجةٍ عاليةٍ جدًّا من الاحتمال) عن بصمة الرسالة الأصلية. كما أنّ الخصمَ يفتقر إلى المفتاح اللازم لتشفير بصمة الرسالة المُفسَدة. لكنّ الخصمَ يستطيع — عبر التنصّت — الحصولَ على الرسالة الأصلية بنصّها الصريح وعلى بصمتها المشفَّرة. ثمّ يستطيع الخصمُ (لأنّ دالةَ التجزئة معروفةٌ عامّة) حسابَ بصمة الرسالة الأصلية وتوليدَ رسائلَ بديلة باحثًا عن واحدةٍ لها البصمةُ ذاتها. فإن وجدها استطاع إرسالَ الرسالة الجديدة مع رمز المصادقة القديم دون أن يُكتشف ذلك. ولهذا فإنّ الأمنَ يتطلّب أن تمتلك دالةُ التجزئة خاصيةَ الاتجاه الواحد (one-way): يجب ألّ تتوفّر طريقةٌ ممكنةٌ حسابيًّا يستطيع بها الخصمُ إيجادُ أيّ رسالةٍ صريحةٍ لها البصمةُ ذاتها التي كانت للأصل.
ولكي تستوفي دالةُ التجزئة هذا المتطلّب، يجب أن تكون نواتجُها موزّعةً توزيعًا عشوائيًّا إلى حدٍّ معقول. فمثلًا إذا كانت البصماتُ بطول 128 بت وموزّعةً توزيعًا عشوائيًّا حقًّا، فأنت ستحتاج في المتوسط إلى تجريب 2127 رسالةً قبل أن تجد رسالةً ثانيةٍ تطابق بصمتُها بصمةَ رسالةٍ معطاة. وإذا لم تكن النواتجُ موزّعةً عشوائيًّا — أي إذا كانت بعضُ النواتج أرجحَ بكثير من غيرها — فقد تستطيع في حالة بعضِ الرسائل إيجادَ رسالةٍ أخرى لها البصمةُ ذاتها بسهولةٍ أكبر بكثير من ذلك، ممّا يخفّض أمنَ الخوارزمية. ولهذا فإنّ التوزيعَ العشوائي لنواتج التجزئة خاصيةٌ مهمّة لهذه الخوارزميات.
وإن كنتَ إنما تبحث عن أيّ تصادم (collision) — أي رسالتين تنتجان البصمةَ ذاتها — فأنت لا تحتاج إلّا إلى حساب بصمات 264 رسالةً فقط، في المتوسط. وهذه الحقيقةُ المفاجئة هي أساسُ «هجوم عيد الميلاد» المذكور أعلاه.
وقد ظهرت على مدى السنين عدةُ خوارزمياتٍ شائعة للتجزئة التشفيرية، منها Message Digest 5 (MD5) وعائلةُ خوارزمية التجزئة الآمنة (Secure Hash Algorithm, SHA). وكانت نقاطُ ضعف MD5 والإصدارات الأقدم من SHA معروفةً منذ بعض الوقت، ما دفع NIST إلى أن توصي بعائلة خوارزمياتٍ تُعرف بـ SHA-3 عام 2015.
وكما أشرنا أعلاه، يمكن إجراءُ تشفير بصمة الرسالة إمّا باستعمال شيفرةِ مفاتيحٍ سرّية أو شيفرةِ مفاتيحٍ عامة. فإن استُعملت شيفرةُ المفاتيح العامة شُفِّرت البصمةُ باستعمال المفتاح الخاصّ للمرسِل، ويستطيع المستقبِل — أو أيّ شخصٍ آخر — فكّ تشفير البصمة باستعمال المفتاح العام للمرسِل. أمّا إذا استُعملت شيفرةُ المفاتيح السرّية فيجب على المرسِل والمستقبِل الاتفاقَ على المفتاح السرّي مسبقًا بطريقةٍ أخرى.
والبصمةُ المشفَّرة بخوارزميةِ مفاتيحٍ عامة باستعمال المفتاح الخاصّ للمرسِل تُسمّى توقيعًا رقميًّا (digital signature)، لأنّها توفّر عدمَ الإنكار (nonrepudiation) على نحوٍ شبيهٍ بما يوفّره التوقيعُ المكتوب. فمستقبِلُ رسالةٍ تحمل توقيعًا رقميًّا يستطيع أن يُثبت لأيّ طرفٍ ثالث أنّ المرسِلَ هو صاحبُ الرسالة حقًّا، لأنّ ذلك الطرفَ الثالث يستطيع استعمالَ المفتاح العام للمرسِل للتحقّق بنفسه. أمّا تشفيرُ البصمة بمفتاحٍ سرّي فلا يملك هذه الخاصية، لأنّ المفتاحَ لا يعرفه إلّا الطرفان؛ فضلًا عن ذلك، وبما أنّ الطرفين يعرفان المفتاحَ، فالمستقبِلُ المزعوم هو نفسه من كان بإمكانه إنشاءُ الرسالة. ويمكن استعمالُ أيّ شيفرةِ مفاتيحٍ عامة للتوقيعات الرقمية. وقد أصدر NIST سلسلةً من معايير التوقيع الرقمي (Digital Signature Standards, DSS). ويتيح أحدثُ هذه المعايير وقتَ كتابة هذا الكتاب استعمالَ ثلاث شيفراتٍ للمفاتيح العامة: واحدةٌ قائمةٌ على RSA، وأخرى قائمةٌ على المنحنيات البيضاوية، وثالثةٌ تُسمّى خوارزميةَ التوقيع الرقمي بمنحنيات إدوارد (Edwards-Curve Digital Signature Algorithm).
وتُعدّ مقاربةٌ بديلةٌ شائعةُ الاستعمال لتشفير التجزئة هي استعمال دالةِ تجزئةٍ تأخذ قيمةً سرّية (مفتاحًا لا يعرفه إلّا المرسِلُ والمستقبِل) كمعاملِ إدخالٍ إلى جانب نصّ الرسالة. وتُخرج هذه الدالةُ رمزَ مصادقةِ رسالةٍ يكون دالّةً في آنٍ واحد للمفتاح السرّي ومحتوى الرسالة. ويُلحِق المرسِلُ رمزَ مصادقة الرسالة المحسوبَ برسالة النصّ الصريح. ويعيد المستقبِلُ حسابَ رمز المصادقة باستعمال النصّ الصريح والقيمة السرّية، ثمّ يقارنُ الرمزَ المعادَ حسابُه بالرمز الوارد في الرسالة. وتُسمّى أكثرُ المقاربات شيوعًا لتوليد هذه الرموز HMACs، أي رموزَ مصادقةِ الرسائل بتجزئةٍ مفتاحية (keyed-hash message authentication codes).
ويمكن لـ HMACs أن تستعمل أيَّ دالةِ تجزئةٍ من النوع الموصوف أعلاه، لكنّها تُدخل المفتاحَ أيضًا كجزءٍ من المادة التي ستُجزَّأ، بحيث تصبح HMAC دالّةً في المفتاح وفي النصّ المُدخَل معًا. وقد وحّدت NIST بشكلٍ معياريّ طريقةَ حساب HMACs، وهي تأخذ الصيغةَ التالية:
HMAC = H( (K⊕opad) || H((K⊕ipad) || text) )
حيث H هي دالةُ التجزئة، وK هو المفتاح، وopad (وسادةُ الإخراج) وipad (وسادةُ الإدخال) سلسلتان معروفتان تُعرَضان مع المفتاح بعملية XOR (⊕). والرمز || يمثّل الدمج (concatenation).
ويخرج الشرحُ المتعمّق لدالة HMAC هذه عن نطاق هذا الكتاب. غير أنّه قد أُثبت أنّ هذه المقاربة آمنة ما دامت دالةُ التجزئة الأساسية H تمتلك خصائصَ مقاومة التصادم المناسبة الموصوفة أعلاه. ولاحظ أنّ HMAC تأخذ دالةَ تجزئةٍ H غيرَ مفتاحية فتحوّلها إلى تجزئةٍ مفتاحية بإضافة مادة المفتاح إلى النصّ المُدخَل في التجزئة. وتُطبَّق دالةُ التجزئة H مرّتين. أولًا يُلحَق المفتاحُ (بعد تعريضه مع سلسلة، ipad) في مقدّمة الرسالة، ثمّ تُغذّى دالةُ التجزئة بهذه الرسالة. ثمّ يمرّ ناتجُ هذه التجزئة المفتاحية بدوره في تجزئةٍ مفتاحيةٍ أخرى (بتعريض المفتاح أيضًا مع سلسلة، opad، وإلحاقها في مقدّمة ناتج التجزئة المفتاحية الأولى). وتمريرتا دالة التجزئة المفتاحية مهمّتان في إثبات أمن هذا التركيب لـ HMAC.
وحتى هذه اللحظة كنّا نفترض أنّ الرسالةَ ليست سرّية، ومن ثمّ يمكن نقلُ الرسالة الأصلية بوصفها نصًّا صريحًا. ولإضافةِ السرّية إلى رسالةٍ تحمل رمزَ مصادقة، يكفي تشفيرُ دمج الرسالة كاملةً بما فيها رمزُ المصادقة. وتذكّر أنّ السرّيةَ تُنفَّذ عمليًّا باستعمال شيفرات المفاتيح السرّية لأنّها أسرعُ بكثير من شيفرات المفاتيح العامة. فضلًا عن ذلك فإنّ إدراجَ المُصادِق في التشفير لا يكلّف شيئًا تقريبًا بل يزيد الأمانَ.
وفي السنوات الأخيرة حظيت فكرةُ استعمال خوارزميةٍ واحدةٍ تدعم المصادقةَ والتشفير معًا بتأييدٍ متزايدٍ لأسبابٍ تتعلق بالأداء وببساطة التنفيذ. ويشار إلى ذلك بـ التشفير المُصادَق عليه (authenticated encryption) أو التشفير المُصادَق عليه مع بياناتٍ مرتبطة (authenticated encryption with associated data). ويجوز في المصطلح الثاني أن تُنقل بعضُ حقول البيانات (مثل ترويسات الحزم) بصيغةِ النصّ الصريح — وهذه هي البياناتُ المرتبطة — بينما يُشفَّر بقيّةُ الرسالة، وتُصادَق على كلّ شيءٍ فحسب الترويسات. ولن نُعمق في التفاصيل هنا، لكنّه لم يعد ثمّة مجموعةٌ من الخوارزميات المدمجة تُنتج النصّ المشفَّر ورموزَ المصادقة معًا باستعمال مزيجٍ من الشيفرات ودوالّ التجزئة.
وإن كنتَ ترغب في فهمٍ أعمق لمبادئ الشيفرات ودوالّ التجزئة، إلى جانب المفاهيم التشفيرية الأخرى، فإنّنا نوصي بالكتاب التالي.
قراءات إضافية
A. Menezes وP. van Oorschot وS. Vanstone. دليل التشفير التطبيقي. CRC Press، 1996.
والآن، بعد أن رأينا بعضَ لبنات التشفير والمصادقة، تتوفّر لدينا الأسسُ لبناء بعض حلولِ الأمن الكاملة. غير أنّنا، قبل الانتقال إلى تلك الحلول، نعالج مسألةَ كيفية حصول المشاركين على المفاتيح في المقام الأول.
نستعمل participants مصطلحًا عامًّا للدلالة على طرفَي قناة اتصال. وتبعًا لطبقة حزمة الشبكة، قد يقابل المشارك خادمًا أو عمليةً أو صندوق بريد أو تجريدًا آخر من تجريدات النظام. وفي سياق الأمن، كثيرًا ما يُسمّى الطرفان المتواصلان principals، وهذا بدوره يستلزم identity، ثم في نهاية المطاف ارتباطًا بإنسان يمكن محاسبته. ونستعمل مصطلح principal بدلًا من participant حين يكون هذا المعنى الكامل محوريًّا في النقاش. ↩︎