توزيع المفاتيح

لقد رأينا أنّ الشيفرات (ciphers) ورموزَ المصادقة مُشرَكةٌ بمفاتيح. إذن فالمشاركون في الاتصال يحتاجون إلى معرفة المفاتيح التي يستعملونها. أمّا في حالة شيفرة المفاتيح السرّية (secret-key cipher)، فكيف يحصل طرفان على المفتاح الذي يتشاركانه؟ وفي حالة شيفرة المفاتيح العامة (public-key cipher)، فكيف يعلم أحدُ المشاركين أيَّ مفتاحٍ عامٍّ يخصّ مشاركًا آخر مختارًا؟ ولِلإجابة عن هذين السؤالين، نحتاج أوّلًا إلى فهم أنّ ثمّة صنفين مختلفين من المفاتيح يجب اعتبارهما: مفاتيحَ جلساتٍ (session keys) قصيرةَ العمر، ومفاتيحَ مُوزَّعةً مسبقًا (predistributed keys) أطولَ عمرًا.

ومفتاحُ الجلسة (session key) هو مفتاحٌ يُستعمل لتأمين حلقة اتصالٍ واحدةٍ قصيرةِ نسبيًا: وهي الجلسة. وقد يكون ذلك، مثلًا، وصلةَ HTTPS واحدةً بين عميلٍ وخادم. وكلُّ جلسةٍ مختلفةٍ بين زوجٍ من المشاركين تستعمل مفتاحَ جلسةٍ جديدًا، وهو دائمًا مفتاحٌ سرّيٌّ لأجل السرعة. ويحدّد المشاركون مفتاحَ الجلسة الذي يستعملونه بواسطة بروتوكولٍ (protocol) — وهو بروتوكولُ إنشاء مفتاح الجلسة. ويحتاج بروتوكولُ إنشاء مفتاح الجلسة إلى أمنٍ خاصٍّ به (بحيث لا يتمكّن الخصم (adversary) مثلًا من معرفة مفتاح الجلسة الجديد)؛ ويقوم هذا الأمن على المفاتيح المُوزَّعة مسبقًا الأطول عمرًا.

وهناك سببان رئيسيّان لهذا القسمةِ للعمل بين مفاتيح الجلسات والمفاتيح المُوزَّعة مسبقًا:

• تقييدُ المدّةِ التي يُستعمل فيها المفتاحُ يؤدّي إلى وقتٍ أقلّ للهجمات المكلفةِ حاسوبيًّا، ونصٍّ مشفَّرٍ أقلّ يتيح تحليلَه، ومعلوماتٍ أقلّ تكشَف في حال كسر المفتاح.
• شيفراتُ المفاتيح العامة أفضلُ عمومًا في المصادقة الأولية (authentication) وفي إنشاء مفاتيح الجلسات، لكنّها بطيئةٌ جدًّا لاستعمالها في تشفير حركةٍ (traffic) ضخمةٍ من أجل السرّية.

يشرح هذا الفصل كيف تُوزَّع المفاتيحُ المُوزَّعة مسبقًا، ثمّ يشرح كيف تُنشَأ مفاتيحُ الجلسات بعد ذلك. ولاحظ أنّ مفاتيح الجلسات مثالٌ خاصٌّ على سرٍّ مشترك (shared secret)، وأنّ في بعض الحالات نحتاج إلى أكثر من مجرّد مفتاح جلسةٍ بسيط. وفي تلك الحالات نستعمل المصطلحَ الأعمّ «إنشاءُ السرّ المشترك» (shared secret establishment) بدلًا من «توزيع مفتاح الجلسة» (session key distribution). والمبادئُ الأساسية هي نفسها.

ومن الآن فصاعدًا سنستعمل «أليس» (Alice) و«بوب» (Bob) للإشارة إلى المشاركين، كما هو شائعٌ في الأدبيّات المتعلّقة بالتشفير. واحرص على أنّنا وإن كنا نميل إلى الإشارة إلى المشاركين بصيغةِ الصفات الإنسانية، فإنّ ما يشغلنا أكثرَ من ذلك هو الاتصالُ بين كياناتٍ برمجيةٍ أو عتاديةٍ مثل العملاء والخوادم، وهي غالبًا ما تكون بلا علاقةٍ مباشرةٍ بأيّ شخصٍ بعينه.

4.1 التوزيع المسبق للمفاتيح العامة

الخوارزمياتُ المولِّدةُ لزوجٍ متطابقٍ من المفاتيح العامة والخاصة معلومةٌ للعامة، والبرمجياتُ التي تقوم بذلك متاحةٌ على نطاقٍ واسع. فإذا أرادت أليس استعمالَ شيفرةِ مفاتيحٍ عامة، أمكنها أن تولّد زوجَ مفاتيحها العامةَ والخاصةَ، وأن تُبقي المفتاحَ الخاصَّ مخفيًّا، وأن تنشر المفتاحَ العامّ. لكنّ كيف تستطيع أن تنشر مفتاحَها العامّ — أي أن تُقرّ بأنّه يخصّها — بحيث يتمكّن المشاركونَ الآخرون من التأكّد من أنّه حقًّا يخصّها؟ وليس الأمرُ مجرّدَ وضعه في صفحة ويب عامة أو إرساله في رسالة بريد إلكتروني، إذ يمكن للخصم أن يزوّر ادّعاءً واثقًا بالقدر نفسه بأنّ المفتاح x يخصّ أليس، بينما x يخصّ الخصمَ في الواقع.

ويُسمّى المخطَّطُ الكاملُ للتصديق على الارتباطات بين المفاتيح العامة والهويات — أي أيُّ مفتاحٍ يخصّ مَن — البنيةَ التحتية للمفاتيح العامة (Public Key Infrastructure, PKI). وتبدأ البنيةُ التحتية للمفاتيح العامة بالقدرة على التحقّق من الهويات وربطها بالمفاتيح خارج النطاق (out of band). وبعبارةِ «خارج النطاق» نعني شيئًا خارج الشبكة وخارج الحواسيب المكوّنة لها، كما في الأمثلة التالية. فإذا كانت أليس وبوب أشخاصًا يعرف كلٌّ منهما الآخر، لأمكنهما أن يلتقيا في الغرفة نفسها فتعطي أليس مفتاحَها العامّ لبوبٍ مباشرة، ربما على بطاقة عمل. وإذا كان بوب مؤسسةً، فيمكن لأليس، بصفتها شخصًا، أن تقدّم إثباتًا تقليديًّا للهوية، ربما يتضمّن صورةً أو بصمات أصابع. وإذا كانت أليس وبوب حاسوبين تملكهما الشركة نفسها، فيمكن لمدير النظام أن يهيّئ بوب بالمفتاح العامّ لأليس.

ولا يبدو أنّ إنشاء المفاتيح خارج النطاق قابلٌ للتوسّع على نحوٍ جيد، لكنّه يكفي لتهيئة (bootstrap) البنية التحتية للمفاتيح العامة. فمعرفةُ بوب بأنّ مفتاح أليس هو x يمكن نشرُها على نطاقٍ واسع وقابلٍ للتوسّع باستعمال مزيجٍ من التوقيعات الرقمية ومفهومِ الثقة. فمثلًا، لنفترض أنّك تلقّيت مفتاحَ بوب العامّ خارج النطاق، وأنّك تعرف عن بوب ما يكفي للثقة به في مسائل المفاتيح والهويات. عندئذٍ يمكن لبوب أن يرسل إليك رسالةً تقرّ بأنّ مفتاح أليس هو x — وبما أنّك تعرف مفتاحَ بوب العامَّ أصلًا، فيمكنك أن تصدّق على أنّ الرسالة جاءت من بوب. (وتذكّر أنّ بوب، ليوقّع هذا البيان توقيعًا رقميًّا، سيلحق به تجزئةً تشفيريةً (cryptographic hash) مشفَّرةً باستعمال مفتاحه الخاصّ.) وبما أنّك تثق بأنّ بوب سيقول الحقيقة، ستعرف الآن أنّ مفتاح أليس هو x، رغم أنّك لم تلتقِ بها قطّ ولم تتبادل معها رسالةً واحدة.

وباستعمال التوقيعات الرقمية، لا يحتاج بوب حتى إلى إرسال رسالةٍ إليك؛ إذ يكفيه أن ينشئ وينشر بيانًا موقَّعًا رقميًّا بأنّ مفتاح أليس هو x. وتُسمّى هذه الوثيقةُ الموقَّعةُ رقميًّا التي تؤكّد ارتباط مفتاحٍ عامٍّ شهادةَ مفتاحٍ عام (public key certificate)، أو مجرّدَ شهادة (certificate). ويمكن لبوب أن يرسل لأليس نسخةً من الشهادة، أو ينشرها على موقع. وحين يحتاج أحدهم إلى التحقّق من المفتاح العامّ لأليس، يستطيع ذلك بالحصول على نسخةٍ من الشهادة، ربما مباشرةً من أليس — ما دام يثق ببوب ويعرف مفتاحَه العامّ. ويمكنك أن ترى كيف يمكن، انطلاقًا من عددٍ ضئيلٍ جدًّا من المفاتيح (في هذه الحالة، مفتاح بوب وحده)، أن تتراكم مع بمرور الوقت مجموعةٌ كبيرةٌ من المفاتيح الموثوقة. وبوب هنا يؤدّي الدور الذي يُشار إليه عادةً بـ سلطة الشهادات (certificate authority, CA)، ويعتمد أمنُ الإنترنت اليوم إلى حدٍّ بعيدٍ على سلطات الشهادات. وهناك اليوم كثيرٌ من سلطات الشهادات التجارية وغير الربحية المستعملة على نطاقٍ واسع. وقد ترى أيضًا اختصار CA مفسورًا بـ سلطة اعتماد الشهادات (certification authority) — والمعيَنان متكافئان.

ولاحظ أمرًا في المثال أعلاه: فنحن نحتاج إلى معرفة أمرين عن بوب. أوّلًا، نحتاج إلى معرفة مفتاحه العامّ كي نتمكّن من التحقّق من أنّ رسائلَ معيّنةً قد أنشأها بوب. لكنّنا نحتاج أيضًا إلى معرفة أنّ بوب جديرٌ بالثقة بما يكفي كي يصدر بياناتٍ عن مفاتيح الآخرين، وهنا تحديدًا تبرز دورُ سلطات الشهادات (لا الأشخاص العشوائيين). وسنعود إلى هذا الموضوع أدناه.

ومن المعايير الرئيسة للشهادات ما يُعرف بـ X.509. ويترك هذا المعيار تفاصيلَ كثيرةً مفتوحة، لكنّه يحدّد بنيةً أساسية. ومن البديهيّ أنّ الشهادة يجب أن تتضمّن:

• هويةَ الكيان الذي تجري تصديقه
• المفتاحَ العامَّ للكيان الذي تجري تصديقه
• هويةَ الموقِّع
• التوقيعَ الرقمي
• مُعرِّفَ خوارزمية التوقيع الرقمي (أي أيُّ تجزئةٍ تشفيرية وأيّ شيفرة)

إضافةً إلى ذلك، تحتوي الشهاداتُ دائمًا على تاريخ انتهاء صلاحية. وسنرى كيف استُعملت هذه الميزة أدناه.

ولأنّ الشهادةَ تنشئ ارتباطًا بين هويةٍ ومفتاحٍ عام، ينبغي أن ننظر عن قربٍ فيما نعنيه بـ«الهوية». فمثلًا، شهادةٌ تقول «هذا المفتاح العامّ يخصّ جون سميث» (John Smith) لن تكون نافعةً جدًّا إن لم تستطع تحديدُ أيِّ آلاف جون سميث هو المقصود. ولهذا يجب أن تستعمل الشهاداتُ فضاءَ أسماءٍ (name space) محدَّدًا بدقّةٍ للهويات التي تجري تصديقها؛ فمثلًا تُصدَر الشهاداتُ غالبًا لعناوين البريد الإلكتروني ونطاقات DNS.

وهناك طرائقُ مختلفة يمكن بها للبنية التحتية للمفاتيح العامة أن تُضفي صبغةَ رسمية على مفهوم الثقة. وسنناقش المقاربتين الرئيسيتين.

4.1.1 سلطات الشهادات

في النموذج الأول، الثقةُ ثنائية: إمّا أن تثق بشخصٍ تمامًا وإمّا ألّا تثق به البتّة. ومع الشهادات يتيح ذلك بناءَ سلاسل ثقة (chains of trust). فإذا صدّق X أنّ مفتاحًا عامًّا معيّنًا يخصّ Y، ثمّ صدّق Y بدوره أنّ مفتاحًا عامًّا آخر يخصّ Z، فلا بدّ من سلسلةِ شهاداتٍ من X إلى Z، رغم أنّ X وZ ربما لم يلتقيا قطّ. فإذا كنت تعرف مفتاحَ X — وتثق بـ X وY — فبإمكانك تصديقَ الشهادة التي تعطي مفتاح Z. وبعبارةٍ أخرى، كلُّ ما تحتاجه هو سلسلةُ شهاداتٍ وقّعتها جميعًا كياناتٌ تثق بها، ما دامت تعود في نهايتها إلى كيانٍ تعرف مفتاحَه مسبقًا.

وسلطةُ الشهادات أو سلطةُ اعتماد الشهادات (certificate authority, CA) هي كيانٌ يُدَّعى — من قِبل أحدهم — أنّه جديرٌ بالثقة للتحقّق من الهويات وإصدار شهادات المفاتيح العامة. وهناك سلطاتُ شهاداتٍ تجارية وحكومية وغير ربحية. ولاستعمال سلطة شهادات، يجب أن تعرف مفتاحَها هي. غير أنّه يمكنك تعلّم مفتاح تلك السلطة إن استطعت الحصولَ على سلسلةِ شهاداتٍ موقَّعةٍ من قبل سلطات شهاداتٍ تبدأ بسلطةٍ تعرف مفتاحَها مسبقًا. وعندئذٍ يمكنك تصديقُ أيّ شهادةٍ موقَّعةٍ من تلك السلطة الجديدة.

ومن الطرق الشائعة لبناء هذه السلاسل ترتيبُها في تسلسلٍ هرميّ ذي بنية شجرية، كما هو مبيَّن في الشكل 6. فإذا كان يملك الجميعُ المفتاحَ العامَّ لسلطة الشهادات الجذرية، أمكن لأيّ مشاركٍ أن يقدّم سلسلةَ شهاداتٍ إلى مشاركٍ آخر، ويكون واثقًا من أنّها كافيةٌ لبناء سلسلة ثقةٍ له.

الشكل 6. تسلسلٌ هرميٌّ لسلطة الشهادات ذي بنية شجرية.

وهناك مشكلاتٌ جوهريةٌ في بناء سلاسل الثقة. والأهمّ أنّك، حتى لو كنت واثقًا من أنّ لديك المفتاحَ العامَّ لسلطة الشهادات الجذرية، فأنت بحاجةٍ إلى التأكّد من أنّ كلّ سلطة شهاداتٍ في السلسلة، ابتداءً من الجذر، تؤدّي عملها على الوجه الصحيح. فإذا اكتفت واحدةٌ من سلطات الشهادات في السلسلة بأن تُصدر شهاداتٍ لكياناتٍ من دون التحقّق من هويّاتها، فإنّ ما يبدو سلسلةَ شهاداتٍ صالحةً يصبح بلا معنى. فمثلًا، قد تُصدر سلطةُ الشهادات الجذرية شهادةً لسلطة شهاداتٍ من الطبقة الثانية، وتتحقّق بدقّةٍ تامّةٍ من أنّ الاسمَ الوارد في الشهادة يطابق الاسمَ التجاريَّ لسلطة الشهادات، لكنّ تلك السلطة من الطبقة الثانية قد تكون مستعدّةً لبيع شهاداتٍ لأيّ شخصٍ يطلبها، من دون التحقّق من هويّته. وتزداد هذه المشكلةُ سوءًا كلّما طالت سلسلة الثقة. وتوفّر شهادات X.509 خيارَ تقييد مجموعة الكيانات التي يُسمح لموضوع الشهادة بأن يُصادِق على مفاتيحها بدوره.

وقد يكون في شجرة التصديق أكثرُ من جذرٍ واحد، وهذا شائعٌ اليوم مثلًا في تأمين معاملات الويب. إذ تأتي متصفّحاتُ الويب مثل Firefox وChrome مجهّزةً مسبقًا بشهاداتٍ لمجموعةٍ (معقولةِ الحجم) من سلطات الشهادات؛ وبعبارةٍ أخرى، قرّر منتِجُ المتصفّح أنّ هذه السلطات ومفاتيحَها العامةَ المرتبطة يمكن الوثوق بها. ويمكن للمستخدم أيضًا إضافةُ سلطات شهاداتٍ إلى تلك التي يتعرّف عليها متصفّحه على أنّها موثوقة (أو إزالةُ سلطات من القائمة الافتراضية). وبعبارةٍ أخرى، بالنسبة لمعظم المستخدمين، يصبح مُصنِّعُ المتصفّح هو الكيان الذي يثقون به في الإشراف على البنية التحتية للمفاتيح العامة نيابةً عنهم.

وتستعمل الشهاداتُ المُهيّأةَ ليقبلها المتصفّح من قِبل طبقةِ المقابس الآمنة (Secure Socket Layer, SSL) وأمنِ طبقة النقل (Transport Layer Security, TLS)، وهو البروتوكولُ الأكثر استعمالًا لتأمين معاملات الويب، والذي سنناقشه في فصلٍ لاحق. وإن كنت فضوليًّا، فيمكنك التنقّل في إعدادات التفضيلات في متصفّحك والعثور على خيار «عرض الشهادات» لترى كم من سلطات الشهادات مُهيّأً متصفّحُك على الوثوق بها.

4.1.2 شبكة الثقة

والنموذجُ البديل للثقة هو شبكةُ الثقة (web of trust) الذي تجسّده الخصوصيةُ الجيّدة جدًّا (Pretty Good Privacy, PGP)، ونناقشه بمزيدٍ من التفصيل في فصلٍ لاحق. ويستعمل PGP عناوينَ البريد الإلكتروني (من بين خياراتٍ أخرى) بوصفها الهويات التي تُربط بها المفاتيح والتي توقَّع بها الشهادات. وحرسًا على جذور PGP في الحماية من تدخّل الحكومات، لا توجد سلطاتُ شهادات. فبدلًا من ذلك يقرّر كلُّ فردٍ من يثق بهم وبأيّ قدرٍ يثق بهم — وفي هذا النموذج الثقةُ مسألةُ درجة. إضافةً إلى ذلك، يمكن لشهادةِ مفتاحٍ عامٍّ أن تتضمّن مستوىَ ثقةٍ يبيّن مدى يقين الموقِّع بالارتباط بين المفتاح والهوية المدّعَى في الشهادة، فقد يحتاج مستخدمٌ معيّن إلى عدّة شهاداتٍ تشهد على الارتباط نفسه بين مفتاحٍ وهويةٍ قبل أن يقبل الثقةَ به.

فمثلًا، لنفترض أنّ لديك شهادةً لبوب قدّمتها أليس؛ فيمكنك أن تُسند إلى تلك الشهادة مستوىَ ثقةٍ متوسّطًا. لكنّ لديك، إضافةً إلى ذلك، شهاداتٍ أخرى لبوب قدّمتها كارول وديف، وكلاهما جديرٌ أيضًا بالثقة إلى حدٍّ متوسّط، وقد يزيد ذلك من يقينك بأنّ المفتاحَ العامَّ الذي لديك لبوب صحيحٌ إلى حدٍّ كبير. وباختصار، يدرك PGP أنّ مسألةَ إنشاء الثقة مسألةٌ شخصيةٌ إلى حدٍّ كبير، ويمنح المستخدمين المادةَ الأوّليةَ لاتخاذ قراراتهم الخاصّة، بدلًا من افتراض رضاهم جميعًا بالثقة في بنيةٍ هرميةٍ واحدةٍ من سلطات الشهادات. ولكي نقل ما قاله فيل زيمرمان (Phil Zimmerman)، مطوِّر PGP: «PGP موجَّهٌ لمن يفضّلون أن يحمّلوا مظلّاتهم بأنفسهم».

وأصبح PGP شائعًا جدًّا في مجتمع الشبكات، وفي نهاية المطاف تطوَّر إلى معيارٍ للإنترنت يُعرف بـ OpenPGP. وكانت تجمّعاتُ توقيع مفاتيح PGP ميزةً اعتياديةً في اجتماعات IETF. وفي تجمعٍ لتوقيع المفاتيح، يستطيع الفردُ أن:

• يجمع المفاتيحَ العامةَ من أشخاصٍ يعرف هوياتهم (غالبًا بجمع بصمةِ المفتاح — وهي تجزئةٌ قصيرةٌ للمفتاح — من بطاقةٍ مطبوعة).
• يقدّم مفتاحَه العامَّ (أو بصمتَه) إلى آخرين، ربما مبرزًا شكلًا آخر من أشكال الهوية.
• يحصل على توقيعٍ لمفتاحه العامَّ من الآخرين، فيجمع بذلك شهاداتٍ مقنعةً لمجموعةٍ متسعةٍ باستمرارٍ من الأشخاص.
• يوقّع المفتاحَ العامَّ لأشخاصٍ آخرين، مساعدًا إياهم على بناء مجموعة شهاداتهم التي يستطيعون بها نشر مفاتيحهم العامة.
• يجمع شهاداتٍ من أشخاصٍ آخرين يثق بهم بما يكفي لتوقيع المفاتيح.

وهكذا، مع مرور الوقت، يجمع المستخدمون مجموعةً من الشهادات ذات درجات الثقة المختلفة، ويمكن توسيعُ شبكة الثقة وتقويتها.

4.1.3 إبطال الشهادات

ومن المسائل التي تنشأ مع الشهادات مسألةُ كيفية إبطال شهادةٍ أو التراجع عنها. ولماذا هذا مهم؟ لنفترض أنّك تشكّ في أنّ أحدًا قد اكتشف مفتاحَك الخاصّ. فهناك عددٌ لا يُحصى من الشهادات في الكون تقرّ بأنّك مالكُ المفتاح العامّ المقابل لذلك المفتاح الخاصّ. ومن ثمّ فإنّ من اكتشف مفتاحَك الخاصَّ يملك كلَّ ما يلزم لانتحال شخصيتك: شهاداتٍ صالحةً ومفتاحَك الخاصّ. ولحلّ هذه المشكلة، كان من المفيد لو أمكن إبطالُ الشهادات التي تربط مفتاحَك القديمَ المخترَق بهويّتك، بحيث لا يعود المنتحِلُ قادرًا على إقناع الآخرين بأنّه أنت.

والحلُّ الأساسي لهذه المشكلة بسيطٌ بما يكفي. فكلُّ سلطة شهادات تستطيع إصدارَ قائمة إبطال الشهادات (certificate revocation list, CRL)، وهي قائمةٌ موقَّعةٌ رقميًّا بالشهادات التي جرى إبطالُها. وتُحدَّث القائمة دوريًّا وتُتاح للعامة. ولأنّها موقَّعةٌ رقميًّا، يكفي نشرُها على موقع. الآن، حين تستقبل أليس شهادةً لبوب وترغب في التحقّق منها، فإنّها تستشير أوّلًا أحدثَ قائمة إبطالٍ صادرةً عن سلطة الشهادات. ما دامت الشهادةُ لم تُبطَل فهي صالحة. ولاحظ أنّه إذا كانت كلُّ الشهادات ذات عمرٍ غير محدود، لكانت قائمةُ الإبطال تطول باستمرار، إذ لا يمكنك أبدًا إزالةُ شهادةٍ من القائمة خشيةً أن تُستعمل نسخةٌ ما من الشهادة المُبطَلة. ولهذا السبب من الشائع إرفاقُ تاريخ انتهاء صلاحية بالشهادة عند إصدارها. وبذلك يمكننا تقييدُ المدّة التي تحتاج فيها الشهادةُ المُبطَلة إلى البقاء في قائمة الإبطال. وبعد انتهاء تاريخ صلاحيتها الأصلي مباشرةً، يمكن إزالتها من القائمة.

وعمليًّا، تبيّن أنّ إبطالَ الشهادات مسألةٌ صعبة. فقوائمُ الإبطال (CRLs) قد تصبح طويلةً جدًّا الآن بعد انتشار الشهادات على نطاقٍ واسع، فتصبح استعادتُها مكلفة. وقد يقع زمنُ استعادة قائمة الإبطال في المسار الحرج لفتح اتصالٍ بموقع ويب، مما يزيد زمن تحميل الصفحة زيادةً كبيرة. والمهاجمُ العازم الذي اخترق مفتاحًا خاصًّا لديه دافعٌ لتعطيل توزيع قائمة الإبطال، لإطالة المدّة التي يتمكّن فيها من استعمال المفتاح المخترَق. وقد قُدِّمَت عدّةُ مقترحاتٍ لتحسين فاعلية إبطال الشهادات، مثل استعمال متجهاتِ بتّ (bit vectors) أو تمثيلاتٍ مُدمجةٍ أخرى لقائمة الإبطال لتقليل حجمها، وتطويرُ بروتوكول حالة الشهادة عبر الإنترنت (Online Certificate Status Protocol, OCSP) بما يتيح فحوصًا آنيةً لحالة الشهادة. ووقت كتابة هذا الكتاب، توجد بعضُ الممارسات الأفضل للتعامل مع إبطال الشهادات لكن لا يوجد حلٌّ شامل. ويمكن العثور على مناقشةٍ جيدة للقضايا ومقاربةٍ محتملةٍ لإبطال شهاداتٍ أكثرَ فاعليةً في تدوينةِ جون شانك (John Schanck) على المدوّنة.

قراءات إضافية

J. Schanck. CRLite: فحوصٌ سريعةٌ وخاصةٌ وشاملةٌ لإبطال الشهادات في Firefox. مدوّنةُ Mozilla، أغسطس 2025.

4.2 توزيع المفاتيح السرّية

تطرح شيفراتُ المفاتيح السرّية مسألةَ تهيئة (bootstrapping): كيف تحصل بأمانٍ على المفتاح السرّيّ الذي يتشاركه طرفان؟ فإذا أرادت أليس استعمالَ شيفرةِ مفاتيحٍ سرّية للتواصل مع بوب، فلا يكفي أن تختار مفتاحًا وترسله إليه، لأنّهما — ما لم يكونا يملكان مفتاحًا أصلًا — لا يستطيعان تشفيرَ هذا المفتاح لإبقائه سرّيًّا. فضلًا عن ذلك، إن لم يستطعا مصادقةَ بعضهما بعضًا، فلا تستطيع أليس إرسالَ المفتاح بأمانٍ إلى مستقبِلٍ غير مُصادَق. فمثلما في حالة المفاتيح العامة، تلزم هنا مخطّةُ توزيعٍ مسبق. والتوزيعُ المسبق أصعبُ للمفاتيح السرّية منه للمفاتيح العامة، لسببين واضحين:

• فبينما يكفي مفتاحٌ عامٌّ واحدٌ لكل كيانٍ للمصادقة والسرّية، لا بدّ من مفتاحٍ سرّيٍّ لكل زوجٍ من الكيانات التي ترغب في التواصل. وإذا كان ثمّة N كيانات، فذلك يعني N(N-1)/2 مفتاحًا.
• وبخلاف المفاتيح العامة، يجب أن تبقى المفاتيحُ السرّية سرّية.

ولخّص القول، إنّ المفاتيح التي يجب توزيعُها أكثرُ بكثير، ولا يمكنك استعمالُ شهاداتٍ يقرأها الجميع.

ومن الحلول الشائعة استعمالُ عمليات المفاتيح العامة لتهيئة الاتصال. فعلى هذا النحو تُوزَّع مفاتيحُ الشيفرات المتماثلة في HTTPS مثلًا. وسنرى تفصيلًا أكثر عن ذلك لاحقًا.

ومن الحلول الشائعة الأخرى استعمالُ مركز توزيع المفاتيح (Key Distribution Center, KDC). ومركزُ توزيع المفاتيح كيانٌ موثوقٌ يتشارك مفتاحًا سرّيًّا مع كلّ كيانٍ آخر. وهذا يخفض عدد المفاتيح إلى N-1، وهو عددٌ قليلٌ بما يكفي لإنشائه خارج النطاق في بعض التطبيقات. وحين ترغب أليس في التواصل مع بوب، لا يمرّ ذلك التواصل عبر مركز توزيع المفاتيح. بل يشارك مركزُ توزيع المفاتيح في بروتوكولٍ يصحّح هويةَ أليس وبوب — باستعمال المفاتيح التي يتشاركها مع كلٍّ منهما — ويولّد مفتاحَ جلسةٍ جديدًا يستعملانه. ثمّ يتواصل أليس وبوب مباشرةً باستعمال مفتاح الجلسة الخاصّ بهما. وكيربيروس (Kerberos) نظامٌ واسعُ الاستعمال مبنيٌّ على هذه المقاربة. وسنصف كيربيروس (الذي يوفّر المصادقة أيضًا) في الفصل التالي. ويصف القسم التالي بديلًا قويًّا.

4.3 تبادل المفاتيح بين ديفي وهيلمان

ومن المقاربات الواسعة الاستعمال لإنشاء مفتاحٍ سرّيٍّ مشترك استعمالُ بروتوكول تبادل المفاتيح بين ديفي وهيلمان (Diffie-Hellman key exchange)، الذي يعمل من دون استعمال أي مفاتيحَ موزَّعةٍ مسبقًا. فالرسائلُ المتبادلة بين أليس وبوب يمكن لأيّ قادرٍ على التنصّت قراءتها، ومع ذلك لن يعرف المتنصّتُ المفتاحَ السرّيَّ الذي ينتهي إليه أليس وبوب.

ولا يصحّح ديفي وهيلمانُ هويةَ المشاركين. ولأنّ الاتصالَ الآمن نادرًا ما يكون مفيدًا دون التأكّد ممّن تتواصل معه، فإنّ ديفي وهيلمان يُستعمَل عادةً بعد تقويته بصورةٍ ما لتوفير المصادقة. ويُستعمَل ديفي وهيلمان في بروتوكول تبادل المفاتيح عبر الإنترنت (Internet Key Exchange, IKE)، وهو جزءٌ من بنية أمن حزمة IP (IPsec)، وفي أمن طبقة النقل (TLS). ونبدأ مناقشتنا بالمبادئ الأساسية الكامنة وراء ديفي وهيلمان، ثمّ نمضي عبر الخطوات اللازمة لجعله متينًا بما يكفي لاستعماله في أنظمة اليوم.

ولبروتوكول ديفي وهيلمان الأصلي معاملان، هما p وg، وكلاهما عامٌّ ويمكن أن يستعمله جميعُ المستخدمين في نظامٍ معيَّن. ولا بدّ أن يكون المعاملُ p عددًا أوليًّا. والأعداد الصحيحة $\bmod p$ (اختصارًا لعبارة «الباقي القسمة على p») هي من $0$ إلى p-1، لأنّ $x \bmod p$ هو الباقي بعد قسمة x على p، وتشكّل ما يسمّيه الرياضيّون مجموعة (group) تحت الضرب. أمّا المعاملُ g (الذي يُسمّى عادةً «المولِّد») فلا بدّ أن يكون جذرًا أوّليًّا (primitive root) لـ p: فلكلّ عدد n من 1 إلى p-1 يلزم أن توجد قيمةُ k بحيث $n = g^k \bmod p$. فمثلًا، لو كان p هو العدد الأوليّ 5 (والنظامُ الحقيقي سيستعمل عددًا أكبر بكثير)، لأمكننا اختيار 2 مولِّدًا g، إذ:

$$1 = 2^0 \bmod p$$ $$2 = 2^1 \bmod p$$ $$3 = 2^3 \bmod p$$ $$4 = 2^2 \bmod p$$

لنفترض أنّ أليس وبوب يريدان الاتفاق على مفتاحٍ سرّيٍّ مشترك. أليس وبوب، وكلُّ شخصٍ آخر، يعرفون مسبقًا قيمتَي p وg. وتولّد أليس قيمةً خاصّةً عشوائيةً a، ويولّد بوب قيمةً خاصّةً عشوائيةً b. وتُسحَب كلتَي a وb من مجموعة الأعداد الصحيحة $\{1,\dots{}, p-1\}$. ويشتقّ أليس وبوب قيمَهما العامّةَ المقابلة — أي القيمَ التي سيرسلانها إلى بعضهما بعضٍ من دون تشفير — على النحو التالي. أمّا القيمةُ العامّة لأليس فهي

$$g^a \bmod p$$

وأمّا القيمةُ العامّة لبوب فهي

$$g^b \bmod p$$

ثمّ يتبادلان قيمَهما العامّة. وأخيرًا تحسب أليس

$$g^{ab} \bmod p = (g^b \bmod p)^a \bmod p$$

ويحسب بوب

$$g^{ba} \bmod p = (g^a \bmod p)^b \bmod p.$$

أصبح لدى أليس وبوب الآن $g^{ab} \bmod p$ (ويساوي $g^{ba} \bmod p$) بوصفه مفتاحَهما السرّيَّ المشترك.

وسيعرف أيُّ متنصّتٍ قيمتَي p وg والقيمتَين العامّتين $g^a \bmod p$ و$g^b \bmod p$. ولو تمكّن المتنصُّ وحده من تحديد a أو b لأمكنه بسهولة حسابُ المفتاح الناتج. غير أنّ تحديد a أو b انطلاقًا من تلك المعلومات غيرُ ممكنٍ حسابيًّا إذا كان p وa وb كبيرين بما يكفي؛ وتُسمّى هذه المسألة مسألةَ اللوغاريتم المتقطّع (discrete logarithm problem).

ولننظر إلى مثالٍ بأعدادٍ صغيرة لتوضيح الحساب. لنأخذ p = 5 وg = 2، ولنفترض أنّ أليس تختار العددَ العشوائيّ a = 3 وأنّ بوب يختار العددَ العشوائيّ b = 4. عندئذٍ ترسل أليس إلى بوب القيمةَ العامّةَ

$$2^3 \bmod 5 = 3$$

ويرسل بوب إلى أليس القيمةَ العامّةَ

$$2^4 \bmod 5 = 1$$

تستطيع أليس عندئذٍ أن تحسب

$$g^{ab} \bmod p = (2^b \bmod 5)^3 \bmod 5 = (1)^3 \bmod 5 = 1$$

باستبدال القيمةِ العامّة لبوب موضع $(2^b \bmod 5)$. وعلى نحوٍ مشابه، يستطيع بوب أن يحسب

$$g^{ba} \bmod p = (g^a \bmod 5)^4 \bmod 5 = (3)^4 \bmod 5 = 1.$$

باستبدال القيمةِ العامّة لأليس موضع $(2^a \bmod 5)$. ويوافق الآن أليس وبوب معًا على أنّ المفتاحَ السرّيَّ هو $1$.

وكما وصفنا سابقًا، فإنّ غيابَ المصادقة في ديفي وهيلمان يجعله معرّضًا لهجماتٍ متنوّعة. ومن هذه الهجمات هجومُ الوسيط (man-in-the-middle attack). فلنفترض أنّ مولوري (Mallory) خصمٌ قادرٌ على اعتراض الرسائل. ومولوري تعرف أصلًا p وg لأنّهما عامّان، وتولّد قيمتَين خاصّتَين عشوائيّتين هما $c$ و$d$ لاستعمالهما مع أليس وبوب على التوالي. وحين ترسل أليس وبوب قيمَهما العامّة إلى بعضهما بعض، يعترضها مولوري ويرسل قيمَها العامّة الخاصة، كما في الشكل 7. والنتيجةُ أنّ أليس وبوب ينتهيان كلٌّ منهما إلى مشاركة مفتاحٍ مع مولوري بدلًا من مشاركتهِ بعضهما بعض، دون أن تدري.

الشكل 7. هجومُ الوسيط.

ومن الممكن معالجةُ المشكلة الفورية، وهي هجماتُ الوسيط، بتصحيح هوية أحد المشاركين أو كليهما. ويمكننا فعلَ ذلك باستعمال شهاداتٍ شبيهةٍ بشهادات المفاتيح العامة، لكنّها تصدّق بدلًا من ذلك على معاملات ديفي وهيلمان العامّة لكيانٍ ما. فمثلًا، تقول هذه الشهادة إنّ معاملات ديفي وهيلمان لأليس هي p وg و$g^a \bmod p$ (ولاحظ أنّ قيمة a ستبقى معروفةً لأليس وحدها). وهذه الشهادةُ تطمئن بوب إلى أنّ المشاركَ الآخر في ديفي وهيلمان هو أليس — وإلّا فلن يستطيع ذلك المشاركُ الآخر حسابَ المفتاح السرّي، لأنّه لن يعرف a.

والمقاربةُ التي وصفناها للتوّ، وتُعرف بـ ديفي وهيلمان الثابت (fixed Diffie-Hellman)، لا يُوصى بها على نطاقٍ واسع في الممارسة لأنّها تفتقر إلى السرّية التقدّمية (forward secrecy). فإذا اختُرق المفتاحُ الخاصّ طويلُ العمر لأليس في وقتٍ ما، فإنّ الجلسات السابقة التي سجّلها مهاجمٌ تصبح عندئذٍ معرّضةً للخطر. ولهذا السبب يُستعمل على نطاقٍ واسع مقاربةٌ أخرى تُعرف بـ ديفي وهيلمان المؤقّت (ephemeral Diffie-Hellman)، ولا سيّما في TLS.

وكالنسخة الثابتة، يعتمد ديفي وهيلمانُ المؤقّتُ على وجود شهادةٍ صادرةٍ عن سلطة شهاداتٍ لأحد المشاركين على الأقلّ، لكنّها هنا تصدّق على أنّ أليس مرتبطةٌ بمفتاحٍ عامٍّ معيَّن (مثل مفتاح RSA). ثمّ تولّد أليس قيمةً مؤقّتةً لـ a بدلًا من قيمةٍ ثابتة، وتستعمل مفتاحَها الخاصّ لتوقيع معاملات ديفي وهيلمان: p وg و$g^a \bmod p$. وبالتقديم الشهادةِ والقيمةِ الموقَّعة، تستطيع أليس أن تُثبت لبوب أنّ الرسالةَ قد جاءت منها حقًّا، وأن تصدّق على معاملات ديفي وهيلمان، مع الإبقاء على a سرّيةً. وبخلاف ديفي وهيلمان الثابت، توفّر هذه المقاربةُ سرّيةً تقدّمية: فحتى لو اختُرق المفتاحُ الخاصّ طويلُ العمر لأليس، فستبقى الجلساتُ السابقة التي سجّلها مهاجمٌ آمنةً، لأنّها استعملت مفاتيحَ مؤقّتةً تتغيّر مع كلّ جلسة. ولاحظ أنّ كلمة «مؤقّت» لا تعني، بالمعنى الدقيق، إلّا أنّ a قيمةٌ قصيرة العمر؛ لكنّها تُستعمل على نطاقٍ واسع في مواصفات البروتوكولات للإشارة إلى الحالات التي تُجرى فيها المصادقة أيضًا باستعمال مفتاحٍ عامٍّ على النحو الذي وصفناه هنا. ولتجنّب الالتباس، يُشار غالبًا إلى الصيغة الأصلية من ديفي وهيلمان، التي تفتقر إلى المصادقة، بأنّها «الوضع المجهول» (anonymous mode).

وأخيرًا، نلاحظ أنّه إذا كان قد صدر لكلا المشاركين شهادةٌ، فيستطيع كلٌّ منهما تصحيحَ هوية الآخر. وإن لم تصدر شهادةٌ إلّا لأحدهما، فلا يُصحَّح إلّا هويةُ صاحب الشهادة. والمصادقةُ أحاديةُ الاتجاه مستعملةٌ على نطاقٍ واسع على الويب؛ فمثلًا، حين يكون أحدُ المشاركين خادمَ ويب والآخر عميلًا عشوائيًّا، يستطيع العميلُ أن يصحّح هويةَ خادم الويب وأن يُنشئ مفتاحًا سرّيًّا للسرّية قبل أن يرسل رقمَ بطاقة ائتمانٍ إلى خادم الويب.