المصادقة والتفويض
لقد وصفنا حتى الآن كيف نشفّر الرسائل، وكيف نبني رموزَ مصادقة الرسائل، وكيف نوزّع المفاتيح. وقد يبدو أنّ كلّ ما عليك فعله لجعل بروتوكولٍ ما آمنًا هو إلحاقُ رمزِ مصادقةٍ بكلّ رسالة، وإذا أردت السرّية فتشفيرُ الرسالة.
وهناك سببان رئيسيّان لأنّ الأمر ليس بهذه البساطة. أوّلًا، هناك مسألة هجوم إعادة الإرسال (replay attack): خصمٌ يعيد إرسال نسخةٍ من رسالةٍ سُحبت سابقًا. فمثلًا يمكن تخيّل أنّ رسالةً تضع فيها طلبًا لشراء سلعةٍ ما على موقعٍ ما قد تُعاد إعادةُ إرسالها، فيبدو للموقع وكأنّك طلبت مزيدًا من الشيء نفسه. ومع أنّها لم تكن النسخة الأصلية من الرسالة، فإنّ رمزَ مصادقتها يظلّ صالحًا؛ فالرسالةُ في النهاية أُنشئتْ بوشك، ولم تُعدَّل. ومن البديهيّ أنّنا بحاجةٍ إلى حلٍّ يضمن الطزاجة (freshness).
وفي صيغةٍ أخرى من هذا الهجوم تُسمّى هجومَ كبح الإعادة (suppress-replay attack)، قد يكتفي الخصمُ بتأخير رسالتك (باعتراضها ثمّ إعادة إرسالها لاحقًا) كي تُستلم في وقتٍ لم يعد مناسبًا. فمثلًا يمكن للخصم أن يؤخّر طلبك بشراء أسهمٍ من وقتٍ مواتٍ إلى وقتٍ ما كنتَ لن ترغب في الشراء فيه. ومع أنّ هذه الرسالة تكون طازجةً بمعنًى ما (فقد لم تُرسَل من قبل)، فإنّها لن تكون في وقتها. ولهذا نحتاج أيضًا إلى ضمان التوقيت (timeliness). ويمكن النظر إلى الطزاجة والتوقيت بوصفهما جانبَين من السلامة. وضمانُهما سيتطلّب في معظم الحالات بروتوكولَ استجابةٍ ذهابًا وإيابًا غيرَ تافه.
والمسألةُ الثانية التي لم نحلّها بعد هي كيفية إنشاء مفتاح جلسة. ومفتاحُ الجلسة هو مفتاحُ شيفرةٍ سرّية يُولَّد في الحال ويُستعمل لجلسةٍ واحدةٍ فقط. وهذا بدوره يتطلّب بروتوكولًا غيرَ تافه.
والقاسمُ المشترك بين هاتين المسألتَين هو المصادقة (authentication). فإذا لم تكن الرسالةُ طازجةً وفي وقتها، فإنّنا نريد — من الناحية العملية — أن نعدّها غيرَ مصادَق عليها، أي غيرَ صادرةٍ عمّن تدّعي أنّها منه. ومن البديهيّ أيضًا، حين ترتّب لمشاركة مفتاحِ جلسةٍ جديدٍ مع شخصٍ ما، تريد أن تعرف أنّك تشاركه مع الشخص الصحيح. وعمومًا، تُنشِئ بروتوكولاتُ المصادقة مفتاحَ جلسةٍ في الوقت نفسه، بحيث يكون في نهاية البروتوكول قد تصدّق أليس وبوب بعضُهما بعضًا لديهما مفتاحٌ سرّيٌّ جديدٌ يستعملانه. وبدون مفتاحِ جلسةٍ جديد، فإنّ البروتوكول لن يكون سوى تصديقٍ متبادلٍ بين أليس وبوب عند لحظةٍ واحدةٍ في الزمن؛ أمّا مفتاحُ الجلسة فيتيح لهما تصديقَ الرسائل اللاحقة بكفاءة. وعمومًا، تُجري بروتوكولاتُ إنشاء مفتاح الجلسة عمليةَ المصادقة. وكما أشرنا في الفصل الماضي، فإنّ تبادل المفاتيح بين ديفي وهيلمان (Diffie-Hellman) في أبسط صوره لا يوفّر المصادقة، لكنّه في الاستعمال العملي يُدمج دائمًا تقريبًا مع بروتوكول مصادقة.
وهناك مجموعةٌ أساسيةٌ من التقنيات المستعملة لضمان الطزاجة والتوقيت في بروتوكولات المصادقة. وسنصف هذه التقنيات قبل الانتقال إلى بروتوكولاتٍ بعينها.
5.1 تقنياتُ الطزاجة والتوقيت
لقد رأينا أنّ رموزَ المصادقة وحدها لا تتيح لنا كشف الرسائل التي ليست طازجةً أو ليست في وقتها. ومن المقاربات إدراجُ ختمٍ زمنيّ (timestamp) في الرسالة. ومن البديهيّ أنّ الختمَ الزمنيَّ نفسه يجب أن يكون مغلقًا أمام العبث، لذا يجب أن يشمله رمزُ مصادقة الرسالة. والعيبُ الرئيسي في الأختام الزمنية أنّها تتطلّب مزامنةَ ساعاتٍ موزّعة. وبما أنّ نظامَنا سيعتمد عندئذٍ على المزامنة، فإنّ مزامنةَ الساعات نفسها ستحتاج إلى الحماية من التهديدات الأمنية، إلى جانب التحدّيات المعتادة في مزامنة الساعات. وثمة مسألةٌ أخرى هي أنّ الساعات الموزّعة تُزامَن إلى درجةٍ معيّنةٍ فقط — هامشَ خطأٍ معيَّن. وبذلك فإنّ سلامةَ التوقيت التي توفّرها الأختام الزمنية لا تتجاوز جودةَ درجة المزامنة.
ومن المقاربات الأخرى إدراجُ قيمةٍ عشوائيةٍ وحيدة (nonce) — أي عددٍ عشوائيٍّ لا يُستعمل إلّا مرّةً واحدة — في الرسالة. فيستطيع المشاركون كشفَ هجمات إعادة الإرسال بالتحقّق ممّا إذا كانت القيمةُ العشوائية قد استُعملت من قبل. لكنّ هذا بمفرده يتطلّب تتبّعَ القيم العشوائية السابقة، وقد تتراكم منها كمياتٌ كبيرة.
ومن حلول عيوب الأختام الزمنية والقيم العشوائية استعمالُ واحدٍ منهما أو كليهما في بروتوكول تحدٍّ واستجابة (challenge-response). فلنفترض أنّنا نستعمل ختمًا زمنيًّا. وفي بروتوكول تحدٍّ واستجابة، ترسل أليس إلى بوب ختمًا زمنيًّا، وتطلب منه تشفيرَه في رسالة استجابة (إن كانا يتشاركان مفتاحًا سرّيًّا) أو توقيعَه رقميًّا في رسالة استجابة (إن كان لدى بوب مفتاحٌ عامّ، كما في الشكل 8). والختمُ الزمني المشفّر يشبه رمزَ مصادقةٍ يثبت التوقيتَ زيادةً. ويمكن لأليس بسهولة التحقّق من التوقيت في الاستجابة القادمة من بوب، لأنّ ذلك الختمَ قد وَلّدته ساعتها هي — ولا حاجة إلى مزامنة ساعات موزّعة. فلنفترض بدلًا من ذلك أنّ البروتوكول يستعمل قيمًا عشوائية. عندئذٍ لا على أليس سوى تتبّعِ تلك القيم التي ما تزال ردودُها قائمةً ولم تمضِ عليها مدّةٌ طويلة؛ فأيّ استجابةٍ مدَّعَية تحمل قيمةً عشوائية غيرَ معروفة يجب أن تكون زائفة.
الشكل 8. بروتوكولُ تحدٍّ واستجابة.
وجمالُ بروتوكول التحدّي والاستجابة يكمن في أنّه يجمع بين التوقيت والمصادقة؛ فبعد كلّ شيء، بوب وحده (وربما أليس أيضًا، إن كانت الشيفرة بمفتاحٍ سرّيّ) هو من يعرف المفتاحَ الضروري لتشفير الختم الزمني أو القيمة العشوائية التي لم تُرَ من قبل. وتُستعمل الأختامُ الزمنية أو القيمُ العشوائية في معظم بروتوكولات المصادقة التالية.
5.2 بروتوكولاتُ المصادقة بالمفاتيح العامة
وفي المناقشة التالية نفترض أنّ المفتاحَين العامَّين لأليس وبوب قد توزّعا مسبقًا بينهما بوسيلةٍ ما كما وُصف في الفصل السابق. وقد يشمل ذلك الحالةَ التي ترفق فيها أليس شهادتها في أول رسالةٍ ترسلها إلى بوب، والحالةَ التي يبحث فيها بوب في نوعٍ ما من البنية التحتية للمفاتيح العامة عن شهادةٍ تخصّ أليس حين يتلقّى أولَ رسالةٍ منها.
ونصف هنا بروتوكولَ مصادقةٍ بسيطًا يستعمل الأختامَ الزمنية، وهو موضَّحٌ في الشكل 9. وفي هذا البروتوكول ترسل أليس إلى بوب رسالةً موقَّعةً رقميًّا تتضمّن ختمًا زمنيًّا من ساعتها المحلّية وهويّتها. ولأنّ ساعتَيهما غير متزامنتَين، لا يستطيع بوب التأكّد من أنّ الرسالة طازجة. فيردّ بوب رسالةً موقَّعةً رقميًّا تتضمّن الختمَ الزمنيَّ الأصلي لأليس، وختمًا زمنيًّا جديدًا ولّده محلّيًّا، وهويّته. ويستطيع أليس التحقّق من طزاجة ردّ بوب بمقارنة وقتها الحاليّ بالختم الزمني الذي انطلق منها. ثمّ ترسل أليس إلى بوب رسالةً موقَّعةً رقميًّا تتضمّن ختمَه الزمنيَّ الأصلي ومفتاحَ جلسةٍ جديدًا مشفَّرًا باستعمال المفتاح العامّ لبوب. ويستطيع بوب التحقّق من طزاجة الرسالة لأنّ الختمَ الزمني جاء من ساعته هو، فيعرف أنّه يستطيع الوثوق بمفتاح الجلسة الجديد.
والأختامُ الزمنية في هذا المثال تؤدّي في جوهرها دورَ قيمٍ عشوائيةٍ مريحة، وفي الواقع يمكن لهذا البروتوكول أن يستعمل القيمَ العشوائية بدلًا منها. وسنرى بعض الأمثلة على ذلك حين ننظر إلى أمن طبقة النقل (Transport Layer Security, TLS) في فصلٍ لاحق.
الشكل 9. بروتوكولُ مصادقةٍ بالمفاتيح العامة. تقارن أليس ختمَها الزمنيَّ، الموقَّعَ من بوب، بساعتها هي، ويفعل بوب الشيءَ نفسَه بختمِه الموقَّعَ من أليس.
5.3 بروتوكولاتُ المصادقة بالمفاتيح السرّية
لا يكون توزيعُ المفاتيح السرّية مسبقًا على كلّ زوجٍ من الكيانات عمليًّا إلّا في الأنظمة الصغيرة نسبيًّا. وهنا نركّز على الأنظمة الأكبر، حيث يكون لكلّ كيانٍ مفتاحُه الرئيسيّ (master key) الذي لا يتشاركه إلّا مع مركز توزيع المفاتيح (Key Distribution Center, KDC). وفي هذه الحالة، تتضمّن بروتوكولاتُ المصادقة القائمةُ على المفاتيح السرّية ثلاثةَ أطراف: أليس، وبوب، ومركزَ توزيع المفاتيح. والناتجُ النهائي لبروتوكول المصادقة هو مفتاحُ جلسةٍ مشتركٌ بين أليس وبوب يستعملانه للتواصل مباشرةً من دون إشراك مركز توزيع المفاتيح.
الشكل 10. بروتوكولُ مصادقة نيدام-شرويدر.
شكّل بروتوكولُ مصادقة نيدام-شرويدر أساسَ كثيرٍ من أنظمة المصادقة اللاحقة، وهو موضَّحٌ في الشكل 10. ولاحظ أنّ مركز توزيع المفاتيح لا يصحّح في الواقع رسالةَ أليس الأولى ولا يتواصل مع بوب البتّة. وبدلًا من ذلك، يستخدم مركزُ توزيع المفاتيح معرفتهَ بالمفتاحين الرئيسيين لأليس وبوب لبناء ردٍّ لا يفيد أيَّ شخصٍ سوى أليس (لأنّ أليس وحدها تستطيع فكّ تشفيره)، ويحتوي على المكوّناتِ اللازمة ليقوم أليس وبوب بأنفسهما بتنفيذ بقية بروتوكول المصادقة.
وتبدأ العمليّةُ بأن ترسل أليس رسالةً إلى مركز توزيع المفاتيح تتضمّن قيمةً عشوائيةً وحيدةَ وأسماءَ الجهدين (principal) الاثنين، وهما A(lice) وB(ob). ويردّ مركزُ توزيع المفاتيح بأن ينشئ مفتاحَ جلسةٍ جديدًا، ويشفّره بالمفتاح الذي يتشاركه مع بوب (وهو ما تدلّ عليه المغلفُ الداخلي الصغير)، ويضعه في رسالةٍ تُرسَل إلى أليس. ثمّ تُشفَّر هذه الرسالة بدورها باستعمال المفتاح المشترك بين مركز توزيع المفاتيح وأليس (كما تدلّ عليه المغلفُ الخارجي). وهكذا لا تستطيع سوى أليس فكّ تشفير هذه الرسالة، وأصبح لديها الآن مفتاحُ الجلسة غير المشفَّر ونسخةٌ مشفَّرةٌ منه لإرسالها إلى بوب. وحين يستلم بوب الرسالةَ من أليس يتمكّن من فكّ تشفيرها والحصول على مفتاح الجلسة. ثمّ ينشئ قيمةً عشوائيةً أخرى ويشفّرها بمفتاح الجلسة ويردّ بها على أليس. وأخيرًا، تفكّ أليس تشفيرَ القيمة العشوائية، وتزيدها بمقدار واحد، وتردّ على بوب بالنتيجة المشفَّرة، مُثبتةً أنها رأت القيمةَ العشوائية. ومع أنّ القيمةَ العشوائية التي أنشأها بوب واستُعملت في آخر رسالتين تُظهر أنّ الرسالةَ الأخيرة من أليس طازجة، فإنّها لا تضمن طزاجةَ الرسالةِ الأولى التي تلقّاها بوب من أليس في الخطوة 3. ويعالج كيربيروس هذا القصور.
5.3.1 كيربيروس
وكيربيروس نظامُ مصادقةٍ قائمٌ على بروتوكول نيدام-شرويدر ومُخصَّصٌ لبيئات العميل/الخادم. وقد طُوِّر في الأصل في MIT، ثمّ وحّدته IETF وهو متاحٌ بوصفه منتجًا مفتوحَ المصدر ومنتجًا تجاريًّا. وهنا نركّز على بعض الابتكاراتِ اللافتة في كيربيروس. ومن الملحوظ أنّه يعالج مسألةَ الطزاجة التي حدّدها نيدام-شرويدر باستعمال الأختام الزمنية بدلًا من القيم العشوائية.
عملاءُ كيربيروس عمومًا مستخدمونٍ بشريّون، والمستخدمون يصحّحون هوياتهم باستعمال كلمات المرور. أمّا المفتاحُ الرئيسيّ لأليس، الذي يتشاركه مع مركز توزيع المفاتيح، فيُشتقّ من كلمة مرورها — فإذا كنت تعرف كلمةَ المرور استطعتَ حسابَ المفتاح. ويفترض كيربيروس أنّ أيّ شخصٍ يستطيع الوصولَ الماديّ إلى أيّ آلةٍ عميلة؛ ومن ثمّ فإنّ من المهمّ تقليلُ انكشاف كلمة مرور أليس أو مفتاحها الرئيسيّ ليس في الشبكة فحسب بل وعلى أيّ آلةٍ تسجّل الدخولَ إليها أيضًا. ويستفيد كيربيروس من مقاربةٍ مشتقّةٍ من نيدام-شرويدر لتحقيق ذلك. ففي نيدام-شرويدر، الوقتُ الوحيد الذي تحتاج فيه أليس إلى استعمال كلمة مرورها للوصول إلى مفتاحها الرئيسيّ هو حين تفكّ تشفيرَ ردّ مركز توزيع المفاتيح. وينتظر برمجياتُ كيربيروس في جانب العميل حتى يصل ردّ مركز توزيع المفاتيح، ثمّ تطلب من أليس إدخالَ كلمة مرورها، فتحسب المفتاحَ الرئيسيَّ وتفكّ تشفيرَ ردّ مركز توزيع المفاتيح، ثمّ تمحو جميعَ المعلومات المتعلقة بكلمة المرور والمفتاح الرئيسيّ لتقليل انكشافهما. ولاحظ أيضًا أنّ العلامةَ الوحيدة التي يراها المستخدم من كيربيروس هي حين يُطلب منه إدخالُ كلمة المرور.
وفي نيدام-شرويدر، يؤدي ردُّ مركز توزيع المفاتيح إلى أليس دورين: فهو يمنحها وسيلةَ إثبات هويّتها (لأنّ أليس وحدها تستطيع فكّ تشفير الردّ)، ويمنحها أيضًا نوعًا من شهادات المفاتيح السرّية أو «تذكرة» (ticket) تقدّمها إلى بوب — وهي مفتاحُ الجلسة ومُعرِّفُ أليس، مشفَّران بالمفتاح الرئيسيّ لبوب. وفي كيربيروس، يُفصل هذان الدوران — وكذلك مركزُ توزيع المفاتيح ذاتُه عمليًّا — (الشكل 11). فخادمٌ موثوقٌ يُسمّى خادمَ المصادقة (Authentication Server, AS) يؤدّي الدورَ الأول لمركز توزيع المفاتيح، إذ يوفّر لأليس ما تستطيع استعمالَه لإثبات هويّتها — لا تجاه بوب هذه المرّة، بل تجاه خادمٍ موثوقٍ ثانٍ يُسمّى خادمَ منح التذاكر (Ticket Granting Server, TGS). ويؤدّي خادمُ منح التذاكر الدورَ الثاني لمركز توزيع المفاتيح، فيردّ على أليس بتذكرةٍ تستطيع تقديمها إلى بوب. وجمالُ هذا المخطّط أنّه إذا احتاجت أليس إلى التواصل مع عدّة خوادم، لا مع بوب وحده، أمكنها الحصولُ على تذاكرَ لكلٍّ منها من خادم منح التذاكر من دون العودة إلى خادم المصادقة.
ومتى تستلم أليس التذكرةَ من خادم المصادقة، تستطيع التواصلَ مع خادم منح التذاكر. وهي تقدّم له التذكرة، ومُعرِّفَ بوب، وختمًا زمنيًّا مشفَّرًا (بدلًا من القيمة العشوائية المستعملة في نيدام-شرويدر). ويردّ خادمُ منح التذاكر بتذكرةٍ يستطيع بوب قراءتَها، لأنّها مشفَّرةٌ بمفتاحه الرئيسيّ، وبمفتاحِ جلسةٍ مشفَّرٍ باستعمال المفتاح المشترك بين أليس وخادم منح التذاكر. وبذلك تستطيع أليس الآن بدءُ التواصل مع بوب، مُرسِلةً التذكرةَ وختمًا زمنيًّا آخر مشفَّرًا باستعمال مفتاح الجلسة الجديد المُقدَّم.
وفي مجال تطبيقات العميل/الخادم الذي صُمِّم له كيربيروس، يكون من المعقول افتراضُ درجةٍ من مزامنة الساعات. ويتيح ذلك لكيربيروس استعمالَ الأختام الزمنية وأعمارَ الصلاحية بدلًا من القيم العشوائية في نيدام-شرويدر. وهذا يعني أنّ خادمَ منح التذاكر وبوب كلاهما يمكنه الطمأنينةُ إلى أنّ الرسائلَ القادمة من أليس طازجةٌ وليست إعادةَ إرسال، ومن ثمّ يُلغى ضعفُ الأمان في نيدام-شرويدر الذي أشرنا إليه أعلاه. أمّا طزاجةُ ردّ بوب إلى أليس فهي مضمونةٌ لأنّه استجابةٌ لتحدّي أليس.
وقد خضع كيربيروس لتطويرٍ وتوحيدِ قياسيٍّ كبيرٍ على مدى العقود. وهو يدعم مجموعةَ خياراتٍ من دوالّ التجزئة وشيفرات المفاتيح السرّية، وقد سمح له ذلك بالتطوّر مع المعايير الخاصّة بالخوارزميات التشفيرية.