البحث في الموقع

سنتعرف في هذا المقال على آلية مفاتيح التوزيع المسبَق Key Predistribution وبروتوكولات الاستيثاق Authentication Protocols المستخدمة لتحقيق أمن الشبكات الحاسوبية مفتاح التوزيع المسبق Key Predistribution يحتاج المشاركون المتصلون إلى معرفة المفاتيح الواجب استخدامها لدى استخدام الشيفرات ciphers والمستوثقات authenticators، ولكن كيف يحصل المشاركان على المفتاح المُشترك بينهما في حالة تشفير المفتاح السري؟ وكيف يعرف المشارِكان ما هو المفتاح العام الذي ينتمي إلى مشاركٍ معين في حالة تشفير المفتاح العام؟ تختلف الإجابة اعتمادًا على ما إذا كانت المفاتيح هي مفاتيح جلسةٍ قصيرة العمر أو مفاتيح موزَّعةً مسبقًا وأطول عمرًا. مفتاح الجلسة session key هو مفتاحٌ يُستخدم لتأمين حلقة اتصالٍ واحدةٍ قصيرة نسبيًا تسمى جلسة، حيث تستخدم كل جلسةٍ مميزة بين زوج من المشاركين مفتاحَ جلسةٍ جديد، وهو دائمًا مفتاحٌ سري لسرعته، حيث يحدد المشاركون مفتاح الجلسة الواجب استخدامه عن طريق بروتوكول إنشاء مفتاح الجلسة، والذي يحتاج إلى الأمن الخاص به بحيث لا يستطيع الخصم معرفة مفتاح الجلسة الجديد على سبيل المثال، ويعتمد هذا الأمن على المفاتيح الموزَّعة مسبقًا والأطول عمرًا. هناك نوعان من الدوافع الأساسية لتقسيم العمل بين مفاتيح الجلسة والمفاتيح الموزعة مسبقًا هما: يؤدي تحديد مقدار الوقت الذي يُستخدم فيه المفتاح إلى تقليل وقت الهجمات الحسابية المكثفة computationally intensive attacks، وتقليل النص المشفر لتحليل التشفير، وكذلك المعلومات المُعرضة للخطر في حالة كسر المفتاح. تتفوق شيفرات المفاتيح العامة على الاستيثاق وإنشاء مفتاح الجلسة، لكنها بطيئة جدًا في تشفير الرسائل بأكملها من أجل الخصوصية. يشرح هذا القسم كيفية توزيع المفاتيح الموزعة مسبقًا، وسيشرح القسم التالي كيفية إنشاء مفاتيح الجلسة بعد ذلك، حيث سنستخدم من الآن فصاعدًا "ريم" و"أنس" لتحديد المشاركين (الشائع في أدبيات التشفير في المراجع الأجنبية هو أليس Alice وبوب Bob ولكن بدلناهما إلى أسماء عربية ليقابل أليس ريم وبوب أنس للتسهيل على القارئ العربي). ضع في حساباتك أنه على الرغم من أننا نميل إلى الإشارة إلى المشاركين بمصطلحات مجسّمة، إلا أننا كثيرًا ما نهتم بالاتصال بين كيانات البرامج أو الأجهزة مثل العملاء والخوادم، التي غالبًا لا تكون لها علاقةٌ مباشِرة مع أي شخصٍ معين. توزيع المفاتيح العامة المسبق Predistribution of Public Keys الخوارزميات الخاصة بإنشاء زوجٍ متطابقٍ من المفاتيح العامة والخاصة معروفةٌ للجميع، والبرامج التي تُنشئها متاحةٌ على نطاقٍ واسع؛ لذلك إذا أرادت ريم استخدام شيفرة cipher المفتاح العام، فيمكنها إنشاء زوجها الخاص من المفاتيح العامة والخاصة، وإبقاء المفتاح الخاص مخفيًا ونشر المفتاح العام، ولكن كيف يمكنها نشر مفتاحها العام بطريقة تجعل المشاركين الآخرين متأكدين من أنه حقًا يخصها؟ بالتأكيد لن يكون عبر البريد الإلكتروني أو الويب، لأن الخصم يمكن أن يزوّر ادعاءً مقبولًا بأن المفتاح x ينتمي إلى ريم عندما يكون x ينتمي إلى الخصم في الحقيقة. يُطلق على المخطط الكامل للمصادقة على الارتباطات بين المفاتيح العامة والهويات (أي ما هو المفتاح ولمن ينتمي) اسم البنية التحتية للمفتاح العام Public Key Infrastructure أو اختصارًا PKI، حيث تبدأ البنية التحتية PKI بالتحقق من الهويات وربطها بمفاتيح خارج النطاق، ونعني بعبارة "خارج النطاق" شيئًا ما خارج الشبكة والحواسيب التي تتكون منها، كما هو الحال عندما تكون ريم وأنس أفرادًا يعرفون بعضهم بعضًا، حيث يمكنهم الاجتماع معًا في نفس الغرفة، كما يمكن أن تمنح ريم المفتاح العام لأنس مباشرةً؛ وإذا كان أنس منظمةً، فيمكن لريم (وهي فردٌ هنا) أن تقدم تعريفًا تقليديًا، ربما يتضمن صورةً أو بصمات أصابع؛ أما إذا كانت ريم وأنس حواسيبًا مملوكةً لنفس الشركة، فيمكن لمسؤول النظام ضبط أنس باستخدام مفتاح ريم العام. لن يتوسّع إنشاء مفاتيح خارج النطاق جيدًا، ولكنه يكفي لتمهيد bootstrap البنية التحتية PKI، حيث يمكن نشر معرفة أنس بأن مفتاح ريم هو x على نطاقٍ واسع باستخدام مجموعة من التوقيعات الرقمية digital signatures ومفهوم الثقة. لنفترض مثلًا أنك تلقيت مفتاح أنس العام خارج النطاق وأنك تعرف ما يكفي عن أنس لتثق به في أمور المفاتيح والهويات، هنا يمكن أن يرسل أنس إليك رسالةً يؤكد فيها أن مفتاح ريم هو x، وبما أنك تعرف بالفعل مفتاح أنس العام، فيمكنك استيثاق الرسالة على أنها واردةٌ من أنس. تذكر أنه للتوقيع رقميًا على بيانٍ ما، سيُلحِق أنس القيمة المُعمَّاة المُشفَّرة cryptographic hash به باستخدام مفتاحه الخاص. وبما أنك تثق في أن أنس سيقول الحقيقة، فستعرف الآن أن مفتاح ريم هو x، على الرغم من أنك لم تقابلها مطلقًا ولم تتبادل معها رسالةً واحدة، ولن يضطر أنس حتى إلى إرسال رسالةٍ إليك باستخدام التوقيعات الرقمية؛ حيث يمكنه ببساطة إنشاء ونشر بيانٍ موقَّع رقميًا يفيد بأن مفتاح ريم هو x. يسمى بيانُ ارتباط المفتاح العام الموقَّع رقميًا *شهادةَ المفتاح العام public key *certificate أو اختصارًا شهادة certificate فقط، ويمكن أن يرسل أنس نسخةً من الشهادة إلى ريم أو ينشرها على موقع ويب. إذا احتاج شخصٌ ما يثق في أنس ويعرف مفتاحه العام للتحقق من مفتاح ريم العام، فيمكنه فعل ذلك من خلال الحصول على نسخةٍ من الشهادة، ربما مباشرةً من ريم؛ وبالتالي يمكنك أن ترى كيفية إنشاء مجموعةٍ كبيرةٍ من المفاتيح الموثوقة بمرور الوقت بدءًا من عددٍ صغيرٍ جدًا من المفاتيح مثل مفاتيح أنس فقط في هذه الحالة، حيث يلعب أنس الدور المُشار إليه غالبًا باسم سلطة الشهادات certification authority أو اختصارًا CA، ويعتمد الكثير من أمن الإنترنت اليوم على سلطة الشهادات مثل سلطة VeriSign، وهي سلطة شهادات تجارية معروفة. يُعرَف معيار X.509 بأحد معايير الشهادات الرئيسية، وهو يترك الكثير من التفاصيل مفتوحةً لكنه يحدد البنية الأساسية، حيث يجب أن تتضمن الشهادة بوضوح ما يلي: هوية identity الكيان المُعتمد. المفتاح العام للجهة المُعتمدة. هوية الموقّع. التوقيع الرقمي. معرّف خوارزمية التوقيع الرقمي أي تحديد القيمة المُعمَّاة المُشفَّرة والمشفّر. هناك مكوّنٌ آخر اختياري وهو وقت انتهاء صلاحية الشهادة، وسنرى استخدامًا خاصًا له أدناه. تنشِئ الشهادة ارتباطًا بين الهوية والمفتاح العام، لذلك يجب أن ننظر عن كثب إلى ما نعنيه بكلمة "الهوية identity"؛ فقد لا تكون الشهادة التي تنص على أن "هذا المفتاح العام ملكٌ لجون سميث" على سبيل المثال مفيدةً للغاية إذا لم تتمكن من معرفة الشخص المحدد الذي اسمه جون سميث من بين آلاف الأشخاص الذين يملكون نفس الاسم، وبالتالي يجب أن تَستخدم الشهادات حيز أسماءٍ محددًا جيدًا للهويات المُعتمَدة، حيث تُصدَر الشهادات لعناوين البريد الإلكتروني ونطاقات DNS على سبيل المثال. هناك طرقٌ مختلفة يمكن للمفاتيح العامة من خلالها إضفاء الطابع الرسمي على مفهوم الثقة، حيث سنناقش النهجين الرئيسيين أدناه. سلطات الشهادات Certification Authorities الثقة ثنائية في نموذج الثقة هذا؛ فإما أن تثق بشخصٍ تمامًا أو لا تثق به أبدًا، حيث يسمح ذلك إضافةً إلى الشهادات، ببناء سلاسلٍ من الثقة. إذا شهد X أن مفتاحًا عامًا معينًا ينتمي إلى Y، ثم شهد Y أن مفتاحًا عامًا آخر ينتمي إلى Z، فهناك سلسلةٌ من الشهادات من X إلى Z، على الرغم من أن X وZ ربما لم يلتقيا أبدًا. أما إذا عرفتَ مفتاح X، وتثق في X وY، فيمكنك أن تثق في الشهادة التي تعطي مفتاح Z، فكل ما تحتاجه هو سلسلةٌ من الشهادات وجميعها موقَّعةٌ من كيانات تثق بها، طالما أنها تؤدي إلى كيانٍ تعرف مفتاحه بالفعل. سلطة الشهادات certification authority أو اختصارًا CA هي كيان يدّعي (باستخدام شخصٍ ما) أنه جديرٌ بالثقة للتحقق من الهويات وإصدار شهادات المفتاح العام، وفي هذا الصدد توجد سلطات شهادات CA تجارية وأخرى حكومية، وهناك سلطات شهادات مجانية. يجب أن تعرِف مفتاح سلطة الشهادات الخاص لاستخدام هذه السلطة، ولكن يمكنك معرفة مفتاح سلطة CA إذا كان بإمكانك الحصول على سلسلةٍ من الشهادات الموّقعة منها والتي تبدأ بسلطة CA التي تعرف مفتاحها بالفعل، ثم يمكنك تصديق أي شهادة موقَّعة من سلطة الشهادات الجديدة تلك. تتمثل إحدى الطرق الشائعة لبناء مثل هذه السلاسل في ترتيبها في تسلسلٍ هرميٍ منظمٍ على شكل شجرة، كما هو موضحٌ في الشكل الآتي. إذا كان لدى كل شخصٍ المفتاح العام لسلطة CA الجذر، فيمكن لأي مشاركٍ تقديم سلسلةٍ من الشهادات لمشاركٍ آخر، وستكون معرفةُ ذلك كافيةً لبناء سلسلة ثقة لذلك المشارك. هناك بعض المشكلات المهمة المتعلقة ببناء سلاسل الثقة، فحتى إذا كنت متأكدًا من أن لديك المفتاح العام لسلطة CA الجذر، فأنت بحاجةٍ للتأكد من أن كل سلطة شهادات من الجذر إلى الأسفل تؤدي عملها بصورةٍ صحيحة. إذا كانت لسلطة شهادات واحدةٌ فقط في السلسلة مستعدةً لإصدار شهادات للكيانات دون التحقق من هوياتها، فإن ما يبدو أنه سلسلةٌ صالحةٌ من الشهادات يصبح بلا معنى؛ فقد تصدر سلطة الشهادات الجذر شهادةً لسلطة شهادات من الدرجة الثانية وتتحقق تمامًا من أن الاسم الموجود في الشهادة يطابق اسم النشاط التجاري لسلطة الشهادات، بينما قد تكون سلطة الشهادات من الدرجة الثانية على استعدادٍ لبيع الشهادات لأي شخصٍ يسأل دون التحقق من هويته، وتزداد هذه المشكلة سوءًا كلما طالت سلسلة الثقة. توفّر شهادات X.509 خيار تقييد مجموعة الكيانات التي يكون فيها موضوع الشهادة موثوقًا للتصديق عليه. يمكن أن يكون هناك أكثر من جذرٍ لشجرة الشهادات وهذا شائعٌ في تأمين معاملات الويب اليوم على سبيل المثال، حيث تُجهّز متصفحات الويب مثل Firefox وInternet Explorer مسبقًا بشهاداتٍ لمجموعةٍ من سلطات CA التي قرّر منتج المتصفح أنها ومفاتيحها يمكن الوثوق بها؛ ويمكن للمستخدم أيضًا إضافة سلطات شهادات إلى تلك السلطات التي يعترف المتصفح بأنها موثوقة. تُقبل هذه الشهادات بواسطة بروتوكول طبقة المقبس الآمنة Secure Socket Layer أو اختصارًا SSL / طبقة النقل الآمنة Transport Layer Security أو اختصارًا TLS، وهو البروتوكول المستخدم غالبًا لتأمين معاملات الويب، والذي نناقشه في قسمٍ لاحق. يمكنك البحث في إعدادات التفضيلات preferences settings لمتصفحك والعثور على خيار "عرض الشهادات view certificates" لمعرفة عدد سلطات الشهادات CA التي ضُبِط المتصفح الخاص بك ليثق بها. شبكة الثقة Web of Trust نموذجٌ بديل للثقة هو شبكة الثقة المتمثلة في نظام خصوصية جيدة جدًا Pretty Good Privacy أو اختصارًا PGP، وهو نظام أمانٍ للبريد الإلكتروني؛ لذا فإن عناوين البريد الإلكتروني هي الهويات التي ترتبط بها المفاتيح والتي تُوقَّع الشهادات بها. لا توجد سلطات CA متماشيةٌ مع أصول نظام PGP المتمثلة في الحماية ضد تدخل الحكومة، حيث يقرر كل فردٍ بمَن يثق ومدى ثقته به، فالثقة لها درجاتٌ في هذا النموذج. يمكن أن تتضمن شهادة المفتاح العام مستوى ثقة يشير إلى مدى ثقة الموقّع بارتباط المفتاح المُطالب به في الشهادة، لذلك قد يتعين على المستخدم الحصول على عدة شهاداتٍ تؤكد على نفس ارتباط المفتاح قبل أن يكون على استعدادٍ للوثوق به. افترض أن لديك شهادةً لأنس مقدمة من ريم مثلًا، حيث يمكنك إسناد مستوىً معتدلًا من الثقة لتلك الشهادة؛ ولكن إذا كانت لديك شهادات إضافية لأنس يوفرها C وD وكلٌ منهما جديرٌ بالثقة إلى حدٍ ما، فقد يزيد ذلك بصورةٍ كبيرة من مستوى ثقتك في أن مفتاح أنس العام الذي لديك صالح. يدرك نظام PGP أن مشكلة بناء الثقة مسألةٌ شخصية تمامًا، ويمنح المستخدمين المادة الخام لاتخاذ قراراتهم الخاصة بدلًا من افتراض أنهم جميعًا على استعداد للثقة في بنيةٍ هرميةٍ واحدة من سلطات CA؛ فعلى حد تعبير فيل زيمرمان Phil Zimmerman وهو مطوّر نظام PGP، فإن "نظام PGP مخصصٌ للأشخاص الذين يفضلون حَزم مظلاتهم الخاصة"، أي الذين لا يثقون إلا بأنفسهم. أصبح نظام PGP شائعًا جدًا في مجتمع الشبكات، وتُعَد حفلات توقيع مفاتيح PGP ميزةً منتظمةً للعديد من أحداث الشبكات مثل اجتماعات IETF، حيث يمكن للفرد في هذه التجمعات: جمع المفاتيح العامة من الأفراد الآخرين الذين يعرف هويتهم. تقديم مفتاحه العام للآخرين. الحصول على مفتاحه العام موقَّعًا من الآخرين، وبالتالي جمع الشهادات التي ستكون مقنعةً لمجموعةٍ كبيرة بصورةٍ متزايدة من الأشخاص. توقيع المفتاح العام للأفراد الآخرين، وبالتالي مساعدتهم على بناء مجموعة الشهادات التي يمكنهم استخدامها لتوزيع مفاتيحهم العامة. جمع الشهادات من الأفراد الآخرين الذين يثق بهم بدرجةٍ كافيةٍ لتوقيع المفاتيح. وبالتالي سيجمع المستخدم مجموعةً من الشهادات بدرجاتٍ متفاوتةٍ من الثقة بمرور الوقت. إبطال الشهادات Certificate Revocation إحدى المشكلات التي تنشأ مع الشهادات هي كيفية إبطال شهادة أو التراجع عنها، وهذا مهم عندما تشك في أن شخصًا ما قد اكتشف مفتاحك الخاص. قد يكون هناك أي عددٍ من الشهادات تؤكد أنك مالك المفتاح العام المقابل لذلك المفتاح الخاص، وبالتالي فإن الشخص الذي اكتشف مفتاحك الخاص لديه كل ما يحتاجه لانتحال شخصيتك مثل شهاداتٍ صالحة ومفتاحك الخاص، ولحل هذه المشكلة سيكون من الجيد أن تكون قادرًا على إبطال الشهادات التي تربط مفتاحك القديم المخترَق بهويتك، حتى لا يتمكن منتحل الشخصية بعد الآن من إقناع الآخرين بأنه أنت. الحل الأساسي للمشكلة بسيطٌ، حيث يمكن لكل سلطة شهادات إصدار قائمة إبطال الشهادات certificate revocation list أو اختصارًا CRL، وهي قائمةٌ موقّعة رقميًا من الشهادات التي جرى إبطالها. تُحدَّث قائمة إبطال الشهادات دوريًا وتُتاح علنًا، وبما أنها موقَّعة رقميًا، فيمكن نشرها على موقع ويب. ستستشير ريم أولًا أحدث قائمة CRL صادرة عن سلطة CA عندما تتلقى شهادةً لأنس تريد التحقق منها، وطالما لم تُبطَل الشهادة فهي صالحة. لاحظ أنه إذا كانت جميع الشهادات لها دورات حياة غير محدودة، فستزداد قائمة CRL دائمًا، حيث لا يمكنك مطلقًا سحب شهادة من قائمة إبطال الشهادات خوفًا من استخدام نسخةٍ من الشهادة التي أُبطِلت؛ لذلك فمن الشائع إرفاق تاريخ انتهاء صلاحية الشهادة عند إصدارها، وبالتالي يمكننا تحديد المدة الزمنية التي تحتاجها الشهادة المُبطَلة للبقاء في قائمة إبطال الشهادات، ويمكن إزالة الشهادة من قائمة إبطال الشهادات بمجرد مرور تاريخ انتهاء الصلاحية الأصلي. توزيع المفاتيح السرية المسبق Predistribution of Secret Keys إذا أرادت ريم استخدام شيفرة المفتاح السري للتواصل مع أنس، فلا يمكنها فقط اختيار مفتاح وإرساله إليه، لأنه لا يمكنهما تشفير هذا المفتاح للحفاظ على سريته، ولايمكنهما استيثاق بعضهما البعض بدون وجود مفتاح بالفعل، فهناك حاجةٌ إلى مخطط التوزيع المسبق كما هو الحال مع المفاتيح العامة. يُعَد توزيع المفاتيح السرية المسبَق أصعب من توزيع المفاتيح العامة المسبَق لسببين واضحين هما: يكفي فقط مفتاحٌ عامٌ واحد لكل كيانٍ للاستيثاق authentication والخصوصية confidentiality، ولكن يجب أن يكون هناك مفتاحٌ سريٌ لكل زوجٍ من الكيانات التي ترغب في الاتصال؛ فإذا كان هناك N كيان، فهذا يعني وجود N(N-1)/2 مفتاح. يجب أن تظل المفاتيح السريةُ سريةً على عكس المفاتيح العامة. أي هناك الكثير من المفاتيح لتوزيعها، ولا يمكنك استخدام الشهادات التي يمكن للجميع قراءتها. الحل الأكثر شيوعًا هو استخدام مركز توزيع مفاتيح Key Distribution Center أو اختصارًا KDC، وهو كيانٌ موثوقٌ يشارك مفتاحًا سريًا مع كل كيانٍ آخر، ويؤدي هذا إلى خفض عدد المفاتيح إلى N-1 مفتاحًا أكثر قابليةً للإدارة، وهذا العدد قليلٌ بما يكفي للإنشاء خارج النطاق من أجل بعض التطبيقات. عندما ترغب ريم في التواصل مع أنس، فلن ينتقل هذا الاتصال عبر مركز توزيع المفاتيح، حيث سيشارك مركز KDC في بروتوكول يستوثق ريم مع أنس باستخدام المفاتيح التي يشاركها مركز KDC فعليًا مع كلٍ منهما، وينشئ مفتاح جلسة جديدًا لهما لاستخدامه، ثم يتواصل أنس وريم مباشرةً باستخدام مفتاح الجلسة. نظام كيربيروس Kerberos هو نظامٌ مستخدمٌ على نطاقٍ واسع يعتمد على هذا النهج، وسنشرح هذا النظام أدناه. تبادل مفاتيح ديفي هيلمان Diffie-Hellman Key Exchange هناك طريقةٌ أخرى لإنشاء مفتاحٍ سري مشترك وهي استخدام بروتوكول تبادل مفاتيح ديفي هيلمان Diffie-Hellman، والذي يعمل دون استخدام أي مفاتيحٍ موزعةٍ مسبقًا، حيث يمكن أن يقرأ أيُّ شخصٍ قادرٍ على التنصت الرسائلَ المتبادلة بين ريم وأنس، ولكن لن يعرف المتنصت المفتاح السري الذي ينتهي به المطاف عند ريم وأنس. لا يستوثق بروتوكول ديفي هيلمان المشاركين، حيث من النادر أن يكون التواصل بصورةٍ آمنة دون التأكد من الشخص الذي تتواصل معه مفيدًا، لذلك فإن بروتوكول ديفي هيلمان عادةً ما يُعزَّز بطريقةٍ ما لتوفير الاستيثاق، وأحد الاستخدامات الرئيسية لبروتوكول ديفي هيلمان هو بروتوكول تبادل مفاتيح الإنترنت Internet Key Exchange أو اختصارًا IKE، وهو جزءٌ مركزيٌ من معمارية أمن IP أو اختصارًا IPsec. يحتوي بروتوكول ديفي هيلمان على معاملين هما p وg، وكلاهما عامان public، ويمكن استخدامهما من قِبل جميع المستخدمين في نظامٍ معين، حيث يجب أن يكون المعامل p عددًا أوليًا. الأعداد الصحيحة mod p (اختصارًا إلى modulo p) هي من 0 إلى p-1، لأن x mod p هو باقي قسمة x على p، وتشكّل ما يسميه علماء الرياضيات مجموعة تحت الضرب group under multiplication. يجب أن يكون المعاملُ g، الذي يسمى عادةً المولّد generator، جذرَ p الأولي primitive، حيث يجب أن تكون هناك قيمة k لكل رقم n قيمته بين 1 وp-1 بحيث: n = gk mod p إذا كان p هو العدد الأولي 5 على سبيل المثال (يمكن أن يستخدم النظام الحقيقي عددًا أكبر بكثير)، فقد نختار العدد 2 ليكون المولد g لأن: 1=20 mod p 2=21 mod p 3=23 mod p 4=22 mod p افترض أن ريم وأنس يريدان الاتفاق على مفتاحٍ سريٍ مشترك، حيث يعرف ريم وأنس والآخرون قيم p وg. تنشئ ريم قيمةً خاصةً عشوائية a ويولّد أنس قيمةً خاصةً عشوائية b، حيث يُستخرَج كلٌ من العددين a وb من مجموعة الأعداد الصحيحة {1,…,p−1}، ويستخرج ريم وأنس القيم العامة المقابلة أي القيم التي سيرسلانها إلى بعضهما بعضًا دون تشفير على النحو التالي: قيمة ريم العامة هي: ga mod p وقيمة أنس العامة هي: gb mod p ثم يتبادلون قيمهم العامة، وتحسب ريم أخيرًا: gab mod p = (gb mod p)a mod p ويحسب أنس: gba mod p = (ga mod p)b mod p ريم وأنس لديهما الآن gab mod p، والتي تساوي gba mod p بمثابة مفتاحٍ سري مشتركٍ بينهما. يمكن أن يعرف أي متنصتٍ العددين p وg والقيمتين العامتين g a mod p وg b mod p؛ فإذا كان المتنصت هو الوحيد الذي يمكنه تحديد العدد a أو العدد b، فيمكنه بسهولة حساب المفتاح الناتج، ولكن تحديد العددين a أو b من تلك المعلومات غير ممكنٍ حسابيًا بالنسبة لأعداد p وa وb الكبيرة بصورةٍ مناسبة، حيث تُعرف هذه المشكلة باسم مشكلة اللوغاريتم المنفصلة discrete logarithm problem. إذا كانت p = 5 وg = 2 على سبيل المثال، وبافتراض أن ريم اختارت العدد العشوائي a = 3 واختار أنس العدد العشوائي b = 4، فترسل ريم إلى أنس القيمة العامة: 23 mod 5=3 ويرسل أنس إلى ريم القيمة العامة: 24 mod 5 = 1 ثم تتمكن ريم من حساب ما يلي عن طريق استبدال قيمة أنس العامة بالقيمة 2 b mod 5. gab mod p = (2b mod 5)3 mod 5 = (1)3 mod 5 = 1 ويستطيع أنس حساب ما يلي عن طريق استبدال قيمة ريم العامة بالقيمة2a mod 5. gba mod p = (2a mod 5)4 mod 5 = (3)4 mod 5 = 1 .يتفق كلٌّ من ريم وأنس الآن على أن المفتاح السري هو 1. يفتقر بروتوكول ديفي هيلمان للاستيثاق، وإحدى الهجمات التي يمكنها الاستفادة من ذلك هي هجوم الوسيط man-in-the-middle. افترض أن سارة خصمٌ ولديها القدرة على اعتراض الرسائل. تعرف سارة العددين p وg لكونهما عامان، وتولّد قيمًا خاصةً عشوائيةً c وd للاستخدام مع ريم وأنس على التوالي؛ فإذا أرسلت ريم وأنس قيمهما العامة لبعضهما البعض، فستعترضها سارة وترسل قيمها العامة كما في الشكل الآتي، والنتيجة هي أن ريم وأنس ينتهي بهما الأمر بمشاركة مفتاحٍ مع سارة بدلًا من بعضهما البعض دون معرفتهما بذلك. هناك بروتوكولٌ آخر من بروتوكول ديفي هيلمان يُسمى أحيانًا بروتوكول ديفي هيلمان الثابت fixed Diffie-Hellman الذي يدعم استيثاق أحد المشاركين أو كليهما، ويعتمد على شهاداتٍ تشبه شهادات المفاتيح العامة، ولكنه يوثّق بدلًا من ذلك معاملات ديفي هيلمان العامة للكيان، وقد تنص هذه الشهادة على أن معاملات ديفي هيلمان الخاصة بريم هي p وg وga mod p مع ملاحظة أن قيمة a ستظل معروفة لريم فقط. ستؤكد هذه الشهادة لأنس أن المشارك الآخر في بروتوكول ديفي هيلمان هو ريم، وإلا فلن يتمكن المشارك الآخر من حساب المفتاح السري لأنه لا يعرف العدد a؛ فإذا كان لدى كلا المشاركَين شهادات لمعاملات ديفي هيلمان، فيمكنهما الاستيثاق ببعضهما بعضًا؛ وإذا كان لدى أحدهما شهادةً، فيمكن الاستيثاق بتلك الشهادة فقط. هذا مفيدٌ في بعض الحالات عندما يكون مثلًا أحد المشاركين خادم ويب والآخر عميلًا عشوائيًا، فيمكن للعميل الاستيثاق بخادم الويب وإنشاء مفتاحٍ سري للخصوصية قبل إرسال رقم بطاقة ائتمان إلى خادم الويب. بروتوكولات الاستيثاق Authentication Protocols وصفنا حتى الآن كيفية تشفير الرسائل، وبناء المستوثقات authenticators، والتوزيع المسبق للمفاتيح الضرورية، وقد يبدو الأمر كما لو أن كل ما يتعين علينا فعله لجعل البروتوكول آمنًا هو إلحاق مستوثقٍ بكل رسالة، وإذا أردت الخصوصية confidentiality، فشفّر الرسالة. الأمر ليس بهذه البساطة ويوجد سببان رئيسيان لذلك، أولهما مشكلة هجوم إعادة الإرسال replay attack، حيث يعيد الخصم إرسال نسخةٍ من رسالةٍ مُرسَلةٍ مسبقًا؛ فإذا كانت الرسالة طلبًا قدّمته على موقع ويب على سبيل المثال، فستظهر الرسالة المُعاد إرسالها على موقع الويب كما لو أنك طلبت نفس الشيء مرارًا وتكرارًا، وعلى الرغم من أنه لم يكن التجسيد الأصلي للرسالة، إلا أن مستوثقها يظل صالحًا؛ فأنت مَن أنشأتَ الرسالة ولم تُعدَّل أبدًا، لذلك نحن بحاجة إلى حلٍ يضمن الأصالة originality. يوجد شكلٌ مختلف من هذا الهجوم يسمى هجوم قمع إعادة الإرسال suppress-replay attack، فقد يؤخّر الخصم فقط رسالتك عن طريق اعتراضها ثم إعادة إرسالها لاحقًا، بحيث تُستلَم في وقتٍ لم يَعُد مناسبًا، حيث يمكن لخصمٍ أن يؤخّر طلبك لشراء الأسهم من وقتٍ مناسب إلى وقتٍ تصبح فيه غير راغبٍ في الشراء. يمكن أن تكون هذه الرسالة أصليةً إلى حدٍ ما، إلا أنها لن تأتي في الوقت المناسب، لذلك نحتاج أيضًا إلى ضمان دقة التوقيت timeliness. يمكن عدّ الأصالة ودقة التوقيت من جوانب سلامة البيانات integrity، وسيتطلب ضمانها في معظم الحالات بروتوكول ذهابٍ وإياب back-and-forth protocol. المشكلة الثانية التي لم نحلها بعد هي كيفية إنشاء مفتاح جلسة، وهو مفتاح تشفير سري يُنشَأ أثناء التنقل ويُستخدم لجلسةٍ واحدةٍ فقط، وهذا أيضًا ينطوي على بروتوكول آخر. القاسم المشترك بين هاتين المشكلتين هو الاستيثاق، فإذا لم تكن الرسالة أصليةً وفي الوقت المناسب، فمن وجهة نظرٍ عملية نعدًّها غير أصلية، وليست آتيةً مِن مَن تدّعي أنها كذلك. إذا رتّبتَ لمشاركة مفتاح جلسةٍ جديد مع شخصٍ ما، فأنت تريد أن تعرف أنك تشاركه مع الشخص المناسب، لذلك تنشئ بروتوكولات الاستيثاق مفتاح جلسةٍ في نفس الوقت، بحيث يستوثق ريم وأنس في نهاية البروتوكول بعضهما البعض ويصبح لهما مفتاحٌ سري جديد لاستخدامه؛ حيث سيستوثق البروتوكول فقط ريم وأنس في وقتٍ واحد بدون مفتاح جلسةٍ جديد، فيسمح لهما مفتاح الجلسة باستيثاق الرسائل اللاحقة بكفاءة. تجري بروتوكولات إنشاء مفتاح الجلسة الاستيثاق، ولكن الاستثناء الملحوظ هو بروتوكول ديفي هيلمان، كما هو موضحٌ أدناه، لذا فإن مصطلحات بروتوكول الاستيثاق وبروتوكول إنشاء مفتاح الجلسة مترادفان تقريبًا. هناك مجموعةٌ أساسية من التقنيات المستخدمة لضمان الأصالة ودقة التوقيت في بروتوكولات الاستيثاق. سنشرح تلك التقنيات قبل الانتقال إلى بروتوكولات معينة. تقنيات الأصالة ودقة التوقيت لقد رأينا أن المستوثقات وحدها غيرُ قادرةٍ على اكتشاف الرسائل غير الأصلية أو الواصلة في الوقت غير المناسب. تتمثل إحدى الطرق في تضمين علاماتٍ زمنية timestamps في الرسالة، حيث يجب أن تكون العلامة الزمنية نفسها غير قابلة للعبث بها، لذا يجب أن يغطيها الموثّق. العيب الأساسي للعلامات الزمنية هو أنها تتطلب مزامنة الساعة الموزعة، وبما أن نظامنا سيعتمد بعد ذلك على المزامنة، فإن مزامنة الساعة نفسها ستحتاج إلى الحماية ضد التهديدات الأمنية، بالإضافة إلى التحديات المعتادة لمزامنة الساعة. هناك مشكلةٌ أخرى وهي أن الساعات الموزعة تجري مزامنتها إلى درجةٍ معينة فقط مع وجود هامش خطأ معين، وبالتالي تكون سلامة التوقيت التي توفرها العلامات الزمنية جيدةً فقط بمثل درجة جودة التزامن. الطريقة الأخرى هي تضمين رقمٍ خاص nonce في الرسالة، وهو رقمٌ عشوائي يُستخدم مرةً واحدة فقط، حيث يمكن للمشاركين بعد ذلك اكتشاف هجمات إعادة الإرسال من خلال التحقق مما إذا اُستخدِم هذا الرقم الخاص مسبقًا، ولكن يتطلب هذا تتبّعًا للأخطاء السابقة، والتي يمكن أن يتراكم عددٌ كبيرٌ منها. يتمثل أحد الحلول في الجمع بين استخدام العلامات الزمنية والأرقام الخاصة، بحيث يجب أن تكون الأرقام الخاصة فريدةً فقط خلال فترةٍ زمنية معينة، وهذا يقود إلى إمكانية التحكم في ضمان تفرّد الأرقام الخاصة، ويتطلب مزامنة ضعيفةً للساعات فقط. حلٌ آخر لأوجه النقص في العلامات الزمنية والأرقام الخاصة هو استخدام أحدهما أو كليهما في بروتوكول استجابة التحدي challenge-response protocol. لنفترض أننا نستخدم علامةً زمنية في بروتوكول استجابة التحدي، حيث ترسل ريم علامةً زمنية إلى أنس وتتحداه بتشفيرها في رسالة استجابة في حالة مشاركة مفتاح سري، أو توقيعها رقميًا في رسالة استجابة إذا كان لدى أنس مفتاح عام كما في الشكل الآتي. تشبه العلامةُ الزمنية المشفرة المستوثقَ الذي يثبت بالإضافة إلى ذلك دقة التوقيت، حيث يمكن أن تتحقق ريم بسهولة من توقيت العلامة الزمنية في استجابة أنس نظرًا لأن هذه العلامة الزمنية تأتي من ساعة ريم الخاصة، ولا حاجة لمزامنة الساعة الموزعة. افترض بدلًا من ذلك أن البروتوكول يستخدم الرموز الخاصة nonces، هنا ستحتاج ريم فقط إلى تتبّع الأرقام الخاصة لتلك الاستجابات المعلَّقة حاليًا والتي لم تكن معلَّقةً لفترة طويلة؛ حيث يجب أن تكون أي استجابةٍ مزعومةً برقمٍ خاص غير معروف زائفةً. يكمن جمال بروتوكول استجابة التحدي، الذي قد يبدو معقدًا، في أنه يجمع بين دقة التوقيت والاستيثاق؛ حيث يعرف أنس فقط وربما ريم (إذا كانت شيفرة مفتاح سري) المفتاحَ الضروري لتشفير العلامة الزمنية أو الرقم الخاص اللذَين لم يُشاهَدا من قبل. تُستخدَم العلامات الزمنية أو الأرقام الخاصة في معظم بروتوكولات الاستيثاق التالية. بروتوكولات استيثاق المفتاح العام Public-Key Authentication Protocols نفترض في المناقشة التالية أن مفاتيح ريم وأنس العامة موزَّعةٌ مسبقًا على بعضها بعضًا عبر بعض الوسائل مثل البنية التحتية PKI، وذلك حتى نشمل الحالة التي ضَمّنت فيها ريم شهادتها في رسالتها الأولى إلى أنس، والحالة التي يبحث فيها أنس عن شهادةٍ لريم عندما يتلقى رسالتها الأولى. يعتمد هذا البروتوكول الأول الموضح في الشكل السابق على مزامنة ساعتَي ريم وأنس، حيث ترسل ريم إلى أنس رسالةً تحتوي على علامةٍ زمنية وهويتها في نصٍ صرف أصلي plaintext، إضافةً إلى توقيعها الرقمي. يستخدم أنس التوقيع الرقمي لاستيثاق الرسالة والعلامة الزمنية للتحقق من حداثة الرسالة، ثم يرسل أنس رسالةً مرةً أخرى مع علامةٍ زمنية وهويته ضمن نصٍ صرف، بالإضافة إلى مفتاح جلسة جديد مشفَّر لتأمين الخصوصية باستخدام مفتاح ريم العام، وجميعها موقَّعةٌ رقميًا. تستطيع ريم التحقق من أصالة الرسالة وحداثتها، لذا فهي تعلم أن بإمكانها الوثوق بمفتاح الجلسة الجديد، ويمكن زيادة العلامات الزمنية بأرقامٍ خاصة للتعامل مع مزامنة الساعة غير التامة. البروتوكول الثاني الموضح في الشكل الآتي مشابهٌ للبروتوكول الأول لكنه لا يعتمد على مزامنة الساعة، حيث ترسل ريم في هذا البروتوكول مرةً أخرى إلى أنس رسالةً موقَّعةً رقميًا مع علامةٍ زمنية وهويتها، ولا يستطيع أنس التأكد من أن الرسالة حديثة نظرًا لعدم مزامنة ساعاتهما، فيرسل أنس مرةً أخرى رسالةً موقّعةً رقميًا مع علامة ريم الزمنية الأصلية والعلامة الزمنية الجديدة الخاصة به وهويته. يمكن لريم التحقق من حداثة استجابة أنس من خلال موازنة وقتها الحالي مع العلامة الزمنية التي نشأت منها، ثم ترسل إلى أنس رسالةً موقعةً رقميًا مع علامته الزمنية الأصلية ومفتاح جلسة جديد مشفَّر باستخدام مفتاح أنس العام. يستطيع أنس التحقق من حداثة الرسالة لأن العلامة الزمنية جاءت من ساعته، لذلك يعرف أنه يمكنه الوثوق بمفتاح الجلسة الجديد، وتعمل العلامات الزمنية مثل أرقامٍ خاصةٍ مناسبة، وبالفعل يمكن لهذا البروتوكول استخدام الأرقام الخاصة nonces بدلًا من العلامات الزمنية. بروتوكولات استيثاق المفتاح السري Secret-Key Authentication Protocols يكون التوزيع المسبق للمفاتيح السرية لكل زوجٍ من الكيانات عمليًا فقط في الأنظمة الصغيرة إلى حدٍ ما، حيث نركز هنا على الأنظمة الأكبر التي يكون فيها لكل كيان مفتاحٌ رئيسي master key خاصٌ به يشاركه فقط مع مركز توزيع المفاتيح Key Distribution Center أو اختصارًا KDC. تتضمن بروتوكولات الاستيثاق القائمة على المفتاح السري ثلاثة أطراف في هذه الحالة هم ريم وأنس ومركز KDC؛ والمنتج النهائي لبروتوكول الاستيثاق هو مفتاح جلسةٍ مشترك بين ريم وأنس وسيستخدمانه للتواصل مباشرةً، دون إشراك مركز توزيع المفاتيح KDC. يوضح الشكل السابق بروتوكول استيثاق نيدام شرويدر Needham-Schroeder. لاحظ أن مركز توزيع المفاتيح لا يوثّق فعليًا رسالة ريم الأولية ولا يتصل بأنس مطلقًا، حيث يستخدم مركز KDC بدلًا من ذلك معرفته بمفاتيح ريم وأنس الرئيسية لإنشاء ردٍ قد يكون عديم الفائدة لأي شخصٍ آخر غير ريم، لأن ريم فقط هي التي تستطيع فك تشفيره، ويحتوي على المكونات الضرورية لريم وأنس لتنفيذ بقية بروتوكول الاستيثاق. الغرض من الرقم الخاص في أول رسالتين هو التأكيد على أن رد مركز توزيع المفاتيح حديث، وتتضمن الرسالتان الثانية والثالثة مفتاح الجلسة الجديد ومعرّف ريم المشفَّرَين معًا باستخدام مفتاح أنس الرئيسي، وهو نوعٌ من إصدارٍ لشهادة المفتاح العام باستخدام المفتاح السري، وبمثابة بيانٍ موقَّعٍ من مركز KDC، لأن مركز توزيع المفاتيح هو الكيان الوحيد إلى جانب أنس الذي يعرف مفتاح أنس الرئيسي، يفيد بأن مفتاح الجلسة المرفَق مملوكٌ لريم وأنس؛ والهدف من الرقم الخاص في الرسالتين الأخيرتين هو طمأنة أنس بأن الرسالة الثالثة حديثة. نظام كيربيروس Kerberos نظام كيربيروس هو نظام استيثاق يعتمد على بروتوكول نيدام شرويدر ومتخصص في بيئات العميل / الخادم client/server، حيث طُوِّر في الأصل في معهد ماساتشوستس للتكنولوجيا ووحّدته منظمة IETF؛ وهو متاحٌ مثل منتجاتٍ مفتوحة المصدر ومنتجات تجارية. سنركز هنا على بعض ابتكارات نظام كيربيروس المهمة. عملاء كيربيروس هم عمومًا مستخدمون بشريون، ويستوثق المستخدمون أنفسهم باستخدام كلمات المرور. مفتاح ريم الرئيسي الذي شاركته مع مركز توزيع المفاتيح مشتقٌّ من كلمة المرور الخاصة بها؛ فإذا عرفت كلمة المرور، فيمكنك حساب المفتاح. يفترض نظام كيربيروس أن أي شخصٍ يمكنه الوصول فعليًا إلى أي جهاز عميل، لذلك من المهم تقليل انكشاف كلمة مرور ريم أو المفتاح الرئيسي ليس فقط في الشبكة، وإنما على أي جهازٍ تسجّل الدخول إليه أيضًا، حيث يستفيد نظام كيربيروس من بروتوكول نيدام شرويدر لإنجاز ذلك. المرة الوحيدة التي تحتاج فيها ريم في بروتوكول نيدام شرويدر لاستخدام كلمة المرور الخاصة بها هي عند فك تشفير الرد من مركز توزيع المفاتيح؛ حيث ينتظر برنامج عميل كيربيروس حتى وصول رد مركز توزيع المفاتيح ويطالب ريم بإدخال كلمة المرور الخاصة بها، ويحسب المفتاح الرئيسي ويفك تشفير رد مركز توزيع المفاتيح، ثم يمسح جميع المعلومات المتعلقة بكلمة المرور والمفتاح الرئيسي لتقليل انكشافها. لاحظ أيضًا أن الإشارة الوحيدة التي يراها المستخدم على نظام كيربيروس هي عندما يُطلَب من المستخدم إدخال كلمة مرور. يلعب رد مركز KDC في بروتوكول نيدام شرويدر على ريم دورين هما: يمنحها وسيلةً لإثبات هويتها بحيث يمكن لريم فقط فك تشفير الرد. يمنحها نوعًا من شهادة المفتاح السري أو "تذكرة ticket" لتقديمها إلى أنس تتضمّن مفتاح الجلسة ومعرّف ريم المشفَّران باستخدام مفتاح أنس الرئيسي. تُقسَّم هاتان الوظيفتان في نظام كيربيروس ومركز KDC بحد ذاته وهذا موضحٌ في الشكل الآتي، حيث يلعب الخادم الموثوق به المسمَّى خادم الاستيثاق Authentication Server أو اختصارًا AS دورَ مركز KDC في تزويد ريم بشيءٍ يمكنها استخدامه لإثبات هويتها، ليس لأنس هذه المرة ولكن لخادم ثانٍ موثوقٍ به يسمى خادم منح التذاكر Ticket Granting Server أو اختصارًا TGS. يلعب خادم TGS دور مركز KDC الثاني، حيث يرد على ريم بتذكرةٍ يمكنها تقديمها إلى أنس. تكمن جاذبية هذا المخطط في أنه إذا احتاجت ريم إلى التواصل مع عدة خوادم، وليس أنس فقط، فيمكنها الحصول على تذاكر لكل من هذه الخوادم من خادم TGS دون الرجوع إلى خادم AS. يمكن افتراض درجةٍ من مزامنة الساعة في نطاق تطبيق العميل / الخادم الذي يستهدفه نظام كيربيروس، فيتيح ذلك لنظام كيربيروس استخدام العلامات الزمنية ودورات الحياة lifespans بدلًا من الأرقام الخاصة الموجودة في بروتوكول نيدام شرويدر، وبالتالي القضاء على ضعف أمن بروتوكول نيدام شرويدر؛ ويدعم نظام كيربيروس اختيار دوال القيم المُعمَّاة hash functions وشيفرات المفاتيح السرية، مما يسمح له بمواكبة أحدث خوارزميات التشفير. ترجمة -وبتصرّف- للقسمين Key Predistribution وAuthentication Protocols من فصل Network Security من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: الهجمات الأمنية Security Attacks في الشبكات الحاسوبية تأمين الشبكات تأمين الشبكات اللاسلكية مقدمة في تأمين خادوم لينكس كيفية تأمين الخواديم السحابية ضد هجمات حقن SQL النسخة الكاملة من كتاب دليل الأمان الرقمي

لقد رأينا العديد من المكونات المطلوبة لتوفير جانبٍ أو جانبين من جوانب الأمن، حيث تتضمن هذه المكونات خوارزميات التشفير وآليات مفتاح التوزيع المسبق key predistribution الرئيسية وبروتوكولات الاستيثاق authentication protocols. سندرس بعض الأنظمة الكاملة التي تستخدم هذه المكونات في هذا القسم. يمكن تصنيف هذه الأنظمة تقريبًا وفقًا لطبقة البروتوكول التي تعمل فيها؛ حيث تشمل الأنظمة التي تعمل في طبقة التطبيق نظام الخصوصية جيدة جدًا Pretty Good Privacy أو اختصارًا PGP الذي يوفر أمن البريد الإلكتروني، وبروتوكول النقل الآمن Secure Shell أو اختصارًا SSH، وهو وسيلة تسجيل دخول آمنة عن بُعد؛ أما بالنسبة لطبقة النقل، فيوجد معيار أمن طبقة النقل Transport Layer Security أو اختصارًا TLS الخاص بمنظمة IETF، والبروتوكول الأقدم الذي اشتق منه وهو بروتوكول طبقة المقابس الآمنة Secure Socket Layer أو اختصارًا SSL. تعمل بروتوكولات IP Security أو اختصارًا IPsec كما يوحي اسمها في طبقة IP أو طبقة الشبكة، حيث يوفّر معيار 802.11i الحماية عند طبقة الربط الخاصة بالشبكات اللاسلكية. يشرح هذا القسم السمات البارزة لكل من هذه الأساليب. قد تتساءل عن سبب توفير الأمن في العديد من الطبقات المختلفة، وأحد الأسباب هو أن التهديدات المختلفة تتطلب تدابيرًا دفاعيةً مختلفة، وهذا غالبًا ما يُترجم إلى تأمين طبقة بروتوكول مختلفة؛ فإذا كان مصدر قلقك الرئيسي مثلًا هو وجود شخصٍ في المبنى المجاور يتطفل على حركة المرور الخاصة بك أثناء تدفقها بين حاسوبك المحمول ونقطة وصول 802.11 الخاصة بك، فمن المحتمل أنك تريد الأمن في طبقة الربط link layer؛ لكن إذا أردتَ أن تكون متأكدًا حقًا من أنك متصلٌ بموقع المصرِف الذي تتعامل معه وتمنع موظفين فضوليين لدى مزودي خدمة الإنترنت من قراءة جميع البيانات التي ترسلها إلى المصرف، فإن المكان المناسب لتأمين حركة المرور (مثل طبقة النقل) يمتد على طول الطريق من جهازك إلى خادم المصرف، ولا يوجد حلٌ واحد يناسب الجميع في بعض الحالات. تتمتع أنظمة الأمن الموضَّحة أدناه بالقدرة على تغيير خوارزميات التشفير التي تستخدمها، حيث أن فكرة جعل خوارزمية نظام الأمن مستقلة فكرةٌ جيدة جدًا، لأنك لا تعرف أبدًا متى يُثبت أن خوارزمية التشفير المفضلة لديك غير قويةٍ بما يكفي لتحقيق أغراضك؛ وبالتالي سيكون من الجيد أن تتمكن من التغيير بسرعة إلى خوارزميةٍ جديدة دون الحاجة إلى تغيير مواصفات البروتوكول أو تطبيقه. لاحظ تطبيق ذلك من خلال القدرة على تغيير المفاتيح دون تغيير الخوارزمية؛ فإذا تبين أن إحدى خوارزميات التشفير لديك بها عيوب، فسيكون من الرائع ألا تحتاج معمارية الأمن بالكامل إلى إعادة تصميمٍ فورية. نظام Pretty Good Privacy أو اختصارا PGP نظام PGP هو طريقةٌ مستخدمة على نطاقٍ واسع لتوفير أمن البريد الإلكتروني، حيث يوفّر هذا النظام الاستيثاق authentication، والخصوصية confidentiality، وسلامة البيانات data integrity، وعدم الإنكار nonrepudiation. ابتكر فيل زيمرمان Phil Zimmerman نظام PGP في الأصل وتطور إلى معيار منظمة IETF المعروف باسم OpenPGP، ويتميز كما رأينا في قسمٍ سابق باستخدام نموذج "شبكة الثقة web of trust" لتوزيع المفاتيح بدلًا من التسلسل الهرمي الشجري. تعتمد خصوصية نظام PGP واستيثاق المستقبِل على مستقبِل رسالة البريد إلكتروني الذي يملك مفتاحًا عامًا يعرفه المرسل، ويجب أن يكون لدى المرسل مفتاحٌ عام يعرفه المستقبِل لتوفير استيثاق المرسل وعدم الإنكار، وتُوزَّع هذه المفاتيح العامة مسبقًا باستخدام الشهادات والبنية التحتية PKI لشبكة الثقة. يدعم نظام PGP خوارزميتي التشفير RSA وDSS لشهادات المفاتيح العامة، وقد تحدد هذه الشهادات بالإضافة إلى ذلك خوارزميات التشفير التي يدعمها أو يفضلها مالك المفتاح، وتوفّر ارتباطات بين عناوين البريد الإلكتروني والمفاتيح العامة. ضع في بالك المثال التالي، حيث نستخدم نظام PGP لتوفير استيثاق وخصوصية المرسل. افترض أنه لدى ريم رسالة بريد إلكتروني إلى أنس، سيمر تطبيق PGP الخاص بريم بالخطوات الموضحة في الشكل السابق، حيث تُوقَّع الرسالة رقميًا أولًا بواسطة ريم، فالقيم المُعمَّاة MD5 وSHA-1 وSHA-2 هي من بين القيم المُعمَّاة hashes الممكن استخدامها في التوقيع الرقمي، ثم ينشئ تطبيق PGP الخاص بها مفتاح جلسةٍ جديد لهذه الرسالة فقط باستخدام شيفرات المفتاح السري المدعومة مثل شيفرات AES و3DES. بعد ذلك تُشفَّر الرسالة الموقعة رقميًا باستخدام مفتاح الجلسة، ثم يُشفَّر مفتاح الجلسة نفسه باستخدام مفتاح أنس العام ويُلحَق بالرسالة. يُذكّر تطبيق PGP الخاص بريم بمستوى الثقة الذي أسندته سابقًا إلى مفتاح أنس العام، بناءً على عدد الشهادات التي حصلت عليها لأنس وموثوقية الأفراد الذين وقّعوا الشهادات. أخيرًا، يُطبَّق تشفير base64 على الرسالة لتحويلها إلى تمثيلٍ متوافق مع نظام ASCII، ليس من أجل الأمن وإنما لوجوب إرسال رسائل البريد الإلكتروني وفق نظام ASCII. سيعكس تطبيق أنس الخاص بنظام PGP هذه العملية خطوةً بخطوة للحصول على رسالة النص الأصلية وتأكيد توقيع ريم الرقمي ويذكّر أنس بمستوى الثقة المُتمتع به في مفتاح ريم العام عند تلّقي رسالة PGP ضمن رسالة بريد إلكتروني. يتميز البريد الإلكتروني بخصائص معينة تسمح لنظام PGP بتضمين بروتوكول استيثاقٍ مناسب في بروتوكول إرسال البيانات المكوَّن من رسالةٍ واحدة، متجنبًا الحاجة إلى أي تبادلٍ سابق للرسائل وبعض التعقيدات الموضحة سابقًا، حيث يكفي توقيع ريم الرقمي لاستيثاقها. لا يوجد دليلٌ على أن الرسالة جاءت في الوقت المناسب، إلا أنه ليس مضمونًا أن تأتي الرسالة الإلكترونية الصحيحة في الوقت المناسب أيضًا؛ ولا يوجد أيضًا دليل على أن الرسالة أصلية، لكن أنس مستخدم بريد إلكتروني وربما هو شخصٌ متسامحٌ مع الأخطاء ويمكنه التعافي من رسائل البريد الإلكتروني المكررة، والتي ليست واردةً في ظل التشغيل العادي على أية حال. يمكن أن تتأكد ريم من أن أنس فقط هو الذي يمكنه قراءة الرسالة لأن مفتاح الجلسة مُشفَّرٌ بمفتاحه العام، حيث لا يثبت هذا البروتوكول لريم أن أنس موجودٌ بالفعل وأنه تلقى البريد الإلكتروني، إلا أن بريدًا إلكترونيًا موثَّقًا من أنس يعود إلى ريم يمكنه فعل ذلك. تقدم المناقشة السابقة مثالًا جيدًا على السبب الذي يجعل آليات أمن طبقة التطبيق مفيدة، إذ يمكنك من خلال المعرفة الكاملة بكيفية عمل التطبيق فقط اتخاذ الخيارات الصحيحة بشأن الهجمات التي يجب الدفاع عنها (مثل البريد الإلكتروني المزوّر) مقابل الهجمات التي يجب تجاهلها (مثل البريد الإلكتروني المؤخَّر أو المعاد). بروتوكول النقل الآمن يُستخدَم بروتوكول النقل الآمن Secure Shell أو اختصارًا SSH لتوفير خدمة تسجيل الدخول عن بُعد، لتحل محل خدمة Telnet الأقل أمانًا المستخدمة في الأيام الأولى للإنترنت، ويمكن أيضًا استخدامه لتنفيذ الأوامر عن بُعد ونقل الملفات، لكننا سنركز أولًا على كيفية دعم بروتوكول SSH لتسجيل الدخول عن بُعد. يهدف بروتوكول SSH غالبًا إلى توفير استيثاقٍ قوي للعميل والخادم وتوفير سلامة الرسائل، حيث يعمل عميل SSH على جهاز سطح المكتب الخاص بالمستخدم ويعمل خادم SSH على بعض الأجهزة البعيدة التي يريد المستخدم تسجيل الدخول إليها، ويدعم هذا البروتوكول أيضًا الخصوصية، بينما لا توفر خدمة Telnet أيًا من هذه الإمكانات. لاحظ أن مصطلح "SSH" يُستخدم غالبًا للإشارة إلى بروتوكول SSH والتطبيقات التي تستخدمه، حيث تحتاج إلى معرفة أي منها هو المقصود من خلال السياق. ضع في حساباتك اثنين من السيناريوهات لاستخدام بروتوكول SSH، حيث يشترك العاملون عن بُعد غالبًا في مزودي خدمة الإنترنت الذين يقدّمون الألياف عالية السرعة إلى المنزل على سبيل المثال، ويستخدمون مزودي خدمة الإنترنت هذه، إضافةً إلى بعض سلاسل مزودي خدمة الإنترنت الآخرين للوصول إلى الأجهزة التي يشغّلها صاحب العمل؛ هذا يعني أنه عندما يسجّل أحد العاملين عن بُعد الدخول إلى جهازٍ داخل مركز بيانات صاحب العمل، فيمكن أن تمر كلمات المرور وجميع البيانات المرسَلة أو المستلَمة عبر أي عددٍ من الشبكات غير الموثوق بها؛ لذلك يوفّر بروتوكول SSH طريقةً لتشفير البيانات المرسَلة عبر هذه الاتصالات وتحسين قوة آلية الاستيثاق المستخدمة لتسجيل الدخول. يحدث موقفٌ مشابه عندما يتصل العامل المذكور بالعمل باستخدام شبكة لاسلكية عامة في مقهى ستاربكس. استخدامٌ آخر لبروتوكول SSH هو تسجيل دخول عن بعد إلى موجّهٍ router، ربما لتغيير ضبطه أو لقراءة ملفات السجل الخاصة به؛ فمن الواضح أن مسؤول الشبكة يريد أن يتأكد من امكانية تسجيل الدخول إلى الموجّه بصورةٍ آمنة وعدم امكانية تسجيل الدخول للأطراف غير المصرّح لها بذلك، أو اعتراض الأوامر المرسَلة إلى الموجّه، أو اعتراض الخرج المُرسَل إلى المسؤول. يتكون أحدث إصدار من بروتوكول SSH وهو الإصدار 2، من ثلاثة بروتوكولات هي: بروتوكول SSH-TRANS، وهو بروتوكول طبقة نقل transport layer protocol. بروتوكول SSH-AUTH، وهو بروتوكول استيثاق authentication protocol. بروتوكول SSH-CONN، وهو بروتوكول اتصال connection protocol. سنركز على أول بروتوكولين، اللذين يشاركان في تسجيل الدخول عن بعد، وسنناقش بإيجاز الغرض من بروتوكول SSH-CONN في نهاية هذا القسم. يوفّر بروتوكول SSH-TRANS قناةً مشفرةً بين جهازَي العميل والخادم، ويعمل فوق اتصال TCP، حيث تتمثل الخطوة الأولى في أي وقتٍ يستخدم فيه المستخدم تطبيق SSH لتسجيل الدخول إلى جهازٍ بعيد بإعداد قناة SSH-TRANS بين هذين الجهازين. ينشئ الجهازان هذه القناة الآمنة من خلال جعل العميل يستوثق الخادم أولًا باستخدام خوارزمية RSA، ثم ينشئ العميل والخادم مفتاح جلسة من أجل تشفير البيانات المرسلة عبر القناة. يتضمن بروتوكول SSH-TRANS تفاوضًا حول خوارزمية التشفير التي سيستخدمها الجانبان، فقد يختار خوارزمية AES على سبيل المثال، كما يتضمن SSH-TRANS كذلك فحصًا لسلامة الرسائل لجميع البيانات المتبادَلة عبر القناة. المشكلة الوحيدة التي لا يمكننا تجاوزها هنا هي كيفية امتلاك العميل مفتاح الخادم العام الذي يحتاجه لاستيثاق الخادم، فقد يبدو الأمر غريبًا، حيث يخبر الخادمُ العميلَ بمفتاحه العام في وقت الاتصال. يحذّر تطبيق SSH المستخدم في المرة الأولى التي يتصل فيها العميل بخادمٍ معين من أنه لم يتحدث إلى هذا الجهاز من قبل، ويسأل عما إذا أراد المستخدم المتابعة. يُعَد ذلك أمرًا محفوفًا بالمخاطر، لأن بروتوكول SSH غير قادرٍ على استيثاق الخادم بفعالية، فغالبًا ما يقول المستخدمون "نعم" على هذا السؤال. يتذكر تطبيقُ SSH بعد ذلك مفتاحَ الخادم العام، وفي المرة التالية التي يتصل فيها المستخدم بنفس الجهاز، فإنه يوازن هذا المفتاح المحفوظ بالمفتاح الذي يستجيب به الخادم؛ فإذا كانا متطابقَين، فإن بروتوكول SSH يستوثق الخادم؛ وإذا كانا مختلفَين، فسيحذّر تطبيق SSH المستخدم مرةً أخرى من وجود خطأ ما، ومن ثم يُمنَح المستخدم فرصةً لإيقاف الاتصال. يمكن للمستخدم الحَذِر بدلًا من ذلك معرفة مفتاح الخادم العام من خلال آليةٍ خارج النطاق وحفظه على جهاز العميل، وبالتالي عدم المخاطرة "للمرة الأولى" أبدًا. الخطوة التالية لإنشاء قناة SSH-TRANS هي بتسجيل المستخدم الدخول فعليًا إلى الجهاز، أو بصورةٍ أكثر تحديدًا استيثاق نفسه على الخادم، حيث يسمح بروتوكول SSH بثلاث آليات مختلفة لفعل ذلك؛ إذ يتواصل الجهازان عبر قناةٍ آمنة في الآلية الأولى، لذلك لا بأس أن يرسل المستخدم كلمة المرور الخاصة به إلى الخادم. هذا ليس بالأمر الآمن عند استخدام بروتوكول Telnet، حيث ستُرسَل كلمة المرور بصورةٍ واضحة، ولكن تشفَّر كلمة المرور في قناة SSH-TRANS في حالة بروتوكول SSH؛ بينما تستخدم الآلية الثانية تشفير المفتاح العام، ويتطلب ذلك أن يضع المستخدم بالفعل مفتاحه العام على الخادم؛ أما الآلية الثالثة المُسماة الاستيثاق المستند إلى المضيف host-based authentication، فتنص على الوثوق تلقائيًا بأن أي مستخدمٍ يدّعي أنه فلانٌ من مجموعةٍ معينة من المضيفين الموثوق بهم هو نفس المستخدم الموجود على الخادم. تتطلب آلية الاستيثاق المستندة إلى المضيف أن يستوثق مضيف العميل نفسه على الخادم عند الاتصال لأول مرة، حيث يستوثق بروتوكول SSH-TRANS القياسي الخادم افتراضيًا فقط. نستنتج من هذه المناقشة أن بروتوكول SSH هو تطبيقٌ مباشر إلى حدٍ ما للبروتوكولات والخوارزميات التي رأيناها طوال هذه الجزئية من السلسلة، ولكن جميع المفاتيح الواجب على المستخدم إنشاءها وإدارتها تجعل بروتوكول SSH صعب الفهم، حيث تعتمد الواجهة الصحيحة على نظام التشغيل. تدعم حزمة OpenSSH على سبيل المثال، التي تُشغَّل على معظم أجهزة يونكس، أمرًا يمكن استخدامه لإنشاء أزواج مفاتيح عامة وخاصة، حيث تُخزَّن هذه المفاتيح في ملفاتٍ مختلفة في مجلدٍ ضمن مجلّد المستخدم الرئيسي؛ فمثلًا يسجّل الملف '~/.ssh/knownhosts' المفاتيح لجميع المضيفين الذين سجّل المستخدم الدخول إليهم؛ ويحتوي الملف '~/.ssh/authorizedkeys' على المفاتيح العامة اللازمة لاستيثاق المستخدم عند تسجيل الدخول إلى هذا الجهاز مثل المفاتيح المستخدَمة من جانب الخادم؛ في حين يحتوي الملف '~/.ssh/id_rsa' على المفاتيح الخاصة اللازمة لاستيثاق المستخدم على الأجهزة البعيدة مثل المفاتيح المُستخدمة من جانب العميل. أخيرًا، أثبت بروتوكول SSH أنه نظامٌ مفيد جدًا لتأمين تسجيل الدخول عن بُعد، فوُسِّع أيضًا لدعم التطبيقات الأخرى مثل إرسال البريد الإلكتروني واستلامه، فالفكرة هي تشغيل هذه التطبيقات عبر "نفق SSH" آمن، وتسمى هذه الإمكانية تمرير المنفذ port forwarding وهي تستخدم بروتوكول SSH-CONN. الفكرة موضَّحة في الشكل السابق، حيث نرى عميلًا على المضيف A يتواصل بصورةٍ غير مباشرة مع خادمٍ على المضيف B عن طريق تمرير حركة المرور الخاصة به عبر اتصال SSH. وتسمَّى الآلية بتمرير المنفذ لأنه عندما تصل الرسائل إلى منفذ SSH المعروف على الخادم، سيفك بروتوكول SSH أولًا تشفير المحتويات ثم "يمرر" البيانات إلى المنفذ الفعلي الذي يستمع إليه الخادم. هذا مجرد نوعٍ آخر من الأنفاق، والذي يُستخدَم في هذه الحالة لتوفير الخصوصية والاستيثاق؛ حيث يمكن تقديم شكلٍ من أشكال الشبكة الخاصة الوهمية virtual private network أو اختصارًا VPN باستخدام أنفاق SSH بهذه الطريقة. أمن طبقة النقل باستخدام بروتوكولات TLS وSSL وHTTPS لفهم أهداف التصميم ومتطلباته لمعيار أمن طبقة النقل Transport Layer Security أو اختصارًاTLS، وطبقة المقابس الآمنة Secure Socket Layer أو اختصارًا SSL التي يستند إليها معيار TLS، فمن المفيد التفكير في إحدى المشكلات الرئيسية التي يهدفان إلى حلها؛ حيث أصبح وجود مستوىً معين من الأمن ضروريًا للمعامَلات على الويب، مثل إجراء عمليات شراء بواسطة بطاقة الائتمان عندما أصبحت شبكة الويب العالمية شائعة، وبدأت المؤسسات التجارية في الاهتمام بها. هناك العديد من القضايا المثيرة للقلق عند إرسال معلومات بطاقة الائتمان الخاصة بك إلى حاسوب على الويب، فقد تقلق من أن المعلومات ستُعتَرض أثناء النقل وتُستخدَم لاحقًا لإجراء عمليات شراء غير مصرَّح بها؛ وربما تقلق أيضًا بشأن تفاصيل معاملة مُعدَّلة مثل تغيير مبلغ الشراء وتريد بالتأكيد أن تعرف أن الحاسوب الذي ترسل إليه معلومات بطاقة الائتمان الخاصة بك هو في الواقع ملكٌ للبائع المعني وليس لطرفٍ آخر، وبالتالي نحن بحاجةٍ إلى خصوصية وسلامة واستيثاق معاملات الويب. كان أول حلٍ مستخدمٍ على نطاقٍ واسع لهذه المشكلة هو بروتوكول SSL الذي طوّرته في الأصل شركة Netscape، وبالتالي أصبح أساسَ معيار TLS الخاص بمنظمة IETF. أدرك مصممو معيارَي SSL وTLS أن هذه المشكلات لم تكن خاصةً بمعامَلات الويب التي تستخدم بروتوكول HTTP، وبنوا بدلًا من ذلك بروتوكولًا للأغراض العامة يقع بين بروتوكول تطبيق مثل بروتوكول HTTP وبروتوكول نقل مثل بروتوكول TCP. سبب تسمية "أمن طبقة النقل" هو أن التطبيق يرى طبقة البروتوكول هذه تمامًا مثل بروتوكول النقل العادي باستثناء حقيقة أنه آمن؛ أي يمكن للمرسل فتح الاتصالات وتسليم البايتات للإرسال، وستنقلها طبقة النقل الآمنة إلى المستقبل بالخصوصية والسلامة والاستيثاق اللازم. تُوفَّر أيضًا للتطبيق من خلال تشغيل طبقة النقل الآمنة على بروتوكول TCP، جميعُ الميزات العادية لبروتوكول TCP مثل الوثوقية والتحكم في التدفق والتحكم في الازدحام، وغير ذلك. يبين الشكل التالي هذا الترتيب لطبقات البروتوكول. يُعرَف بروتوكول HTTP عند استخدامه بهذه الطريقة باسم بروتوكول HTTP الآمن Secure HTTP أو اختصارًا HTTPS. لم يتغير بروتوكول HTTP بحد ذاته في الواقع، فهو ببساطة يسلّم ويستلم البيانات من طبقة SSL / TLS بدلًا من طبقة TCP، وقد أُسنِد منفذ TCP افتراضي إلى بروتوكول HTTPS هو 443؛ فإذا حاولت الاتصال بخادمٍٍ على منفذ TCP رقم 443، فيمكن أن تجد نفسك تتحدث إلى بروتوكول SSL / TLS، والذي سيمرر بياناتك عبر بروتوكول HTTP بشرط أن تسير الأمور بصورةٍ جيدة مع الاستيثاق وفك التشفير. تتوفّر عمليات تطبيقٍ مستقلة لبروتوكول SSL / TLS، إلا أنه من الشائع تجميع التطبيق مع تطبيقاتٍ تحتاج إليه مثل متصفحات الويب. وسنركز في ما تبقى من مناقشتنا لأمن طبقة النقل على بروتوكول TLS، حيث أن بروتوكولي SSL وTLS غير متوافقان تشغيليًا interoperable للأسف، إلا أنهما يختلفان في نواحٍ ثانوية فقط، لذلك ينطبق وصف بروتوكول TLS على بروتوكول SSL تقريبًا. بروتوكول المصافحة Handshake Protocol يتفاوض مشاركان لبروتوكول TLS أثناء وقت التشغيل بشأن التشفير الواجب استخدامه، حيث يتفاوضان على اختيار ما يلي: القيمة المُعمَّاة لسلامة البيانات مثل القيم المُعمَّاة MD5 وSHA-1 وغير ذلك، حيث تُستخدم لتطبيق شيفرات استيثاق الرسالة استنادًا على القيمة المُعمَّاة HMACs. شيفرات المفتاح السري لتحقيق الخصوصية مثل شيفرات DES و3DES وAES. نهج إنشاء مفتاح الجلسة مثل خوارزمية ديفي هيلمان Diffie-Hellman وبروتوكولات الاستيثاق بالمفتاح العام باستخدام خوارزمية DSS. قد يتفاوض المشاركون أيضًا على استخدام خوارزمية ضغط، ليس لأنها توفّر مزايا أمنية، ولكن لسهولة تنفيذها عند التفاوض على كل هذه الأشياء الأخرى ولدى اتخاذ قرارٍ بإجراء بعض عمليات البايت المُكلِفة على البيانات. تستخدم شيفرة الخصوصية مفتاحَين في بروتوكول TLS، منها مفتاحٌ لكل اتجاه، أما متّجهي تهيئة وشيفرات HMACs فلها مفاتيح مختلفة للمشاركين أيضًا، وبالتالي تتطلب جلسة TLS ستة مفاتيح فعالة بغض النظر عن اختيار الشيفرات والقيمة المُعمَّاة. يشتق بروتوكول TLS كلًا من هذه المفاتيح من سرٍ رئيسي master secret مشتركٍ واحد؛ وهو قيمةٌ مؤلفة من 384 بت (48 بايت) ومشتقٌ جزئيًا من "مفتاح الجلسة" الذي ينتج عن بروتوكول إنشاء مفتاح جلسة TLS. يسمَّى جزء بروتوكول TLS الذي يتفاوض على الخيارات ويؤسس السر الرئيسي المشترك ببروتوكول المصافحة handshake protocol. يُنفَّذ نقل البيانات الفعلي بواسطة بروتوكول تسجيل record protocol خاص ببروتوكول TLS. إن بروتوكول المصافحة هو في جوهره بروتوكول إنشاء مفتاح جلسة مع سرٍ رئيسي بدلًا من مفتاح جلسة، حيث يدعم بروتوكول TLS الاختيار من بين عدة أساليب لإنشاء مفتاح الجلسة، لذلك فإن هذه الأساليب تستدعي أنواع بروتوكولاتٍ مختلفة مماثلة. يدعم بروتوكول المصافحة الاختيار بين الاستيثاق المتبادل mutual authentication لكلا المشاركَين؛ أو استيثاق مشاركٍ واحد فقط وهذه هي الحالة الأكثر شيوعًا مثل استيثاق موقع ويب دون استيثاق مستخدم؛ أو عدم وجود استيثاق على الإطلاق مثل حجب خوارزمية ديفي هيلمان، وبالتالي يربط بروتوكول المصافحة بين عدة بروتوكولات لإنشاء مفتاح الجلسة في بروتوكولٍ واحد. يوضح الشكل الآتي بروتوكول المصافحة على مستوى عالٍ، حيث يرسل العميل في البداية قائمةً بمجموعات خوارزميات التشفير التي يدعمها، مع ترتيب الأفضلية تنازليًا، ثم يستجيب الخادم ويعطي مجموعةً من خوارزميات التشفير التي اختارها من تلك الخوارزميات التي أدرجها العميل؛ وتحتوي هذه الرسائل أيضًا على رقم العميل الخاص client nonce ورقم الخادم الخاص server nonce، اللذين سيُدمجان على التوالي في إنشاء السر الرئيسي لاحقًا. تكتمل مرحلة التفاوض عند هذه النقطة، ثم يرسل الخادم رسائل إضافية بناءً على بروتوكول إنشاء مفتاح الجلسة المتفاوض عليه، وقد يتضمن ذلك إرسال شهادة مفتاح عام أو مجموعة من معامِلات خوارزمية ديفي هيلمان؛ وإذا طلب الخادم استيثاق العميل، فإنه سيرسل رسالةً منفصلةً تشير إلى ذلك، ثم سيستجيب العميل بجزئه من بروتوكول تبادل المفاتيح المتفاوَض عليه. وبهذا يكون قد أصبح لدى كلٍّ من العميل والخادم المعلومات اللازمة لإنشاء السر الرئيسي. لا يُعد "مفتاح الجلسة" الذي تبادلاه مفتاحًا في الواقع، ولكن يُطلق عليه بروتوكولُ TLS السرَّ الرئيسي المسبَق pre-master secret، حيث يُحسَب السر الرئيسي باستخدام خوارزمية مُعلَن عنها من خلال السر الرئيسي المسبق، ورقم العميل الخاص client nonce، ورقم الخادم الخاص server nonce. يرسل العميل بعد ذلك رسالةً تتضمن قيمةً معمَّاة hash باستخدام المفاتيح المشتقة من السر الرئيسي لجميع رسائل المصافحة السابقة، ويستجيب لها الخادم برسالةٍ مماثلة، فيمكّنهما ذلك من اكتشاف أي تناقضاتٍ بين رسائل المصافحة التي أرسلاها واستقبلاها، مثل أن يعدّل وسيطٌ معترضٌ رسالةَ العميل الأولية غير المشفّرة لتقليل خيارات العميل من خوارزميات التشفير على سبيل المثال. بروتوكول السجل Record Protocol يضيف بروتوكول سجل TLS الخصوصية والسلامة إلى خدمة النقل الأساسية ضمن جلسةٍ أنشأها بروتوكول المصافحة، حيث تكون الرسائل المستقبَلة من طبقة التطبيق كما يلي: مجزَّأة أو مدمجة ضمن كتلٍ ذات حجمٍ مناسب للخطوات التالية. مضغوطةً اختياريًا. سليمةً باستخدام شيفرة HMAC. مشفَّرة باستخدام شيفرة مفتاح سري. ممرَّرة إلى طبقة النقل (عادةً إلى طبقة TCP) للإرسال. يستخدم بروتوكول السجل شيفرة HMAC مثل مستوثق authenticator، حيث تستخدم شيفرة HMAC أية خوارزمية قيمة مُعمَّاة (مثل القيم المُعمَّاة MD5 وSHA-1 وغير ذلك) كان قد تفاوَض عليها المشاركون. سيكون لدى العميل والخادم مفاتيحٌ مختلفة لاستخدامها عند حساب شيفرة HMAC، مما يجعل كسرها أصعب، حيث يُسنَد رقمٌ تسلسلي يُضمَّن عند حساب شيفرة HMAC لكل رسالة بروتوكول سجل؛ فعلى الرغم من أن هذا الرقم التسلسلي غير واضحٍ في الرسالة مطلقًا، لكنه يمنع عمليات إعادة إرسال أو إعادة ترتيب الرسائل، وهذا ضروريٌ لأن بروتوكول TCP يمكنه أن يسلّم رسائلًا متسلسلةً وغير مكررة إلى الطبقة التي فوقه في ظل الافتراضات العادية، ولكن لا تتضمن هذه الافتراضات خصمًا يمكنه اعتراض رسائل TCP أو تعديل الرسائل أو إرسال رسائل زائفة. تُمكِّن ضمانات تسليم بروتوكول TCP طبقةَ النقل الآمنة من الاعتماد على رسالة TLS صحيحة لها الرقم التسلسلي الضمني التالي بالترتيب، وفي ميزةٌ أخرى مهمة لبروتوكول TLS؛ نجد القدرة على استئناف الجلسة، ولفهم الدافع الأصلي وراء ذلك يجب أن نفهم كيف يستخدم بروتوكول HTTP اتصالات TCP؛ حيث تتطلب كلُّ عملية HTTP مثل الحصول على صفحةٍ من الخادم، فتحَ اتصال TCP جديد، وقد يتطلب استرداد صفحةٍ واحدة تحتوي على عدد من الكائنات الرسومية المضمَّنة بها عدةَ اتصالات TCP، ويتطلب فتح اتصال TCP مصافحةً ثلاثيةً قبل أن يبدأ في نقل البيانات. سيحتاج العميل بعد أن يصبح اتصال TCP جاهزًا لقبول البيانات إلى بدء بروتوكول مصافحة TLS، مع أخذ وقتين آخريين على الأقل ذهابًا وإيابًا واستهلاك قدرٍ من موارد المعالجة ومن حيّز نطاق الشبكة التراسلي network bandwidth، قبل إرسال بيانات التطبيق الفعلية، حيث صُمِّمت إمكانية الاستئناف ضمن بروتوكول TLS للتخفيف من هذه المشكلة. تتمثل فكرة استئناف الجلسة في تحسين الاتصال في القضايا التي أنشأ فيها العميل والخادم بعض الحالات المشتركة shared state في الماضي، حيث يُضمّن العميل ببساطة معرّف الجلسة من جلسةٍ محددة مسبقًا في رسالة المصافحة الأولية؛ فإذا وجد الخادم أنه لا يزال لديه حالةٌ لتلك الجلسة وتفاوض على خيار الاستئناف عند إنشاء تلك الجلسة في الأصل، فيمكن للخادم الرد على العميل بإشارةٍ إلى نجاح الاستئناف، ويمكن أن يبدأ نقل البيانات باستخدام الخوارزميات والمعامِلات المتفاوض عليها مسبقًا؛ وإذا لم يتطابق معرّف الجلسة مع أية حالة جلسةٍ مخزَّنة على ذاكرة الخادم المخبئية، أو إذا لم يُسمَح باستئناف الجلسة؛ فسيعود الخادم إلى عملية تبادل المصافحة العادية. سبَّب الاضطرار إلى إجراء مصافحة TCP لكل كائنٍ مضمَّن في صفحة الويب إلى تحميلٍ زائد، بحيث جرى تحسين بروتوكول HTTP في النهاية لدعم الاتصالات الدائمة persistent connections بصورةٍ مستقلة عن بروتوكول TLS، في حين قلّل تحسين بروتوكول HTTP من قيمة استئناف الجلسة في بروتوكول TLS، بالإضافة إلى إدراك أن إعادة استخدام نفس معرّفات الجلسة ومفتاح السر الرئيسي في سلسلة من الجلسات المستأنَفة يمثل مخاطرةً أمنية، لذلك غيّر بروتوكول TLS نهجه للاستئناف في الإصدار رقم 1.3. يرسل العميل إلى الخادم عند الاستئناف، في إصدار بروتوكول TLS رقم 1.3، تذكرةَ جلسة session ticket مبهَمةً ومشفَّرةً ضمن الخادم؛ تحتوي هذه التذكرة على جميع المعلومات المطلوبة لاستئناف الجلسة، ويُستخدَم السر الرئيسي نفسه عبر المصافحة، ولكن السلوك الافتراضي هو إجراء تبادل مفتاح الجلسة عند الاستئناف. أمن IP أو اختصارا IPsec تحدث أكثر الجهود طموحًا لدمج الأمن في شبكة الإنترنت في طبقة IP، فدعمُ معيار IPsec اختياريٌ في الإصدار IPv4 ولكنه إلزاميٌ في الإصدار IPv6. معيار IPsec هو في الواقع إطار عمل (على عكس بروتوكول أو نظام واحد) لتوفير كافة خدمات الأمن التي ناقشناها، حيث يوفر ثلاث درجات من الحرية. 1- أنه معياري للغاية، مما يسمح للمستخدمين أو على الأرجح مسؤولي النظام بالاختيار من بين مجموعةٍ متنوعة من خوارزميات التشفير وبروتوكولات الأمن المتخصصة. 2- يسمح للمستخدمين بالاختيار من قائمةٍ كبيرة من خصائص الأمن، بما في ذلك التحكم في الوصول والسلامة والاستيثاق والأصالة originality والخصوصية. 3- يمكن استخدامه لحماية التدفقات الضيقة مثل الرزم المنتمية إلى اتصال TCP معين والمُرسلة بين مضيفَين أو التدفقات الواسعة مثل جميع الرزم المُتدفقة بين موجّهَين. يتكون معيار IPsec من جزأين عند عرضه من مستوى عالٍ، حيث يتمثل الجزء الأول ببروتوكولين ينفّذان خدمات الأمن المتاحة هما: بروتوكول ترويسة الاستيثاق Authentication Header أو اختصارًا AH، الذي يوفر التحكم في الوصول وسلامة الرسائل بدون اتصال والاستيثاق والحماية من إعادة التشغيل. بروتوكول تغليف الحمولة الأمنية Encapsulating Security Payload أو اختصارًا ESP، الذي يدعم الخدمات نفسها، بالإضافة إلى الخصوصية. يُستخدَم بروتوكول AH نادرًا، لذلك نركز هنا على بروتوكول ESP؛ أما الجزء الثاني فهو لدعم إدارة المفاتيح، والتي تتناسب مع بروتوكول شامل يعرف باسم بروتوكول إدارة المفاتيح الترابطية الخاص بأمن الإنترنت Internet Security Association and Key Management Protocol أو اختصارًا ISAKMP. التجريد الذي يربط هذين الجزأين معًا هو رابطة الأمن security association أو اختصارًا SA، وهي اتصالٌ بسيطٌ أحادي الاتجاه مع خاصيةٍ أو أكثر من خصائص الأمن المتاحة؛ حيث يتطلب تأمين اتصال ثنائي الاتجاه بين زوجٍ من الأجهزة المضيفة المقابلة لاتصال TCP على سبيل المثال، وتكون رابطتين اثنتين من روابط SA على أساس رابطة في كل اتجاه. بروتوكول IP هو بروتوكولٌ عديم الاتصال، إلا أن الأمن يعتمد على معلومات حالة الاتصال، مثل المفاتيح والأرقام التسلسلية. يُسنَد رقمٌ معرّفٌ لرابطة SA عند إنشائها ويُسمى رقم المعرّف دليل معاملات الأمن security parameters index أو اختصارًا SPI للجهاز المستقبِل ويحدِّد الجمعُ بين دليل SPI وعناوين IP الوجهة رابطةَ SA بصورة فريدة، إذ تتضمن ترويسة ESP دليل SPI، بحيث يمكن للمضيف المستقبل تحديد رابطة SA التي تنتمي إليها الرزمة الواردة، وبالتالي تحديد الخوارزميات والمفاتيح الواجب تطبيقها على الرزمة. تُنشَأ روابط SA ويجري التفاوض بشأنها وتعديلها وحذفها باستخدام بروتوكول ISAKMP، ويحدّد هذا البروتوكول صيغ الرزم لتوليد المفاتيح التي سيجري تبادلها وبيانات الاستيثاق؛ وهذه الصيغ ليست مهمةً جدًا، لأنها توفر إطار عمل فقط، حيث يعتمد الشكل الدقيق للمفاتيح وبيانات الاستيثاق على تقنية توليد المفاتيح والشيفرة وآلية الاستيثاق المستخدَمة. لا يحدّد بروتوكول ISAKMP بروتوكولًا معينًا لتبادل المفاتيح، فعلى الرغم من أنه يقترح أحد الاحتمالات، وهو تبادل مفاتيح الإنترنت Internet Key Exchange أو اختصارًا IKE، فالإصدار الثاني من بروتوكول IKE المُسمى IKE v2، هو ما يُستخدَم عمليًا. بروتوكول ESP هو البروتوكول المستخدَم لنقل البيانات بأمان عبر رابطة SA ثابتة، حيث تتبع ترويسةُ ESP ترويسةَ IP في الإصدار IPv4؛ أما في الإصدار IPv6، فترويسة ESP هي ترويسةٌ ملحقة extension header، وتستخدم صيغة هذه الترويسة ترويسةً header وتذييلًا trailer، كما هو موضح في الشكل الآتي. يتيح حقل SPI للمضيف المستقبِل تحديد رابطة الأمن التي تنتمي إليها الرزمة، ويحمي حقل SeqNum من هجمات إعادة الإرسال، بينما يحتوي حقل بيانات الحمولة PayloadData الخاصة بالرزمة على البيانات الموضحة في حقل NextHdr. إذا حُدِّدت الخصوصية، فستُشفَّر البيانات باستخدام أية شيفرةٍ مرتبطةٍ برابطة SA، وسيسجّل حقل PadLength مقدار المساحة المتروكة المُضَافة إلى البيانات؛ حيث تكون الحاشية padding ضروريةً في بعض الأحيان لأن الشيفرة قد تتطلب أن يكون للنص الأصلي عددًا معينًا من البايتات أو من أجل التأكد من أن النص المشفَّر الناتج ينتهي عند حد 4 بايتات. وأخيرًا، يحمل حقل بيانات الاستيثاق AuthenticationData المستوثق authenticator. يدعم معيار IPsec وضع النفق tunnel mode، بالإضافة إلى *وضع النقل transport mode، وتعمل كل رابطة SA في أحد الوضعين. تُعَد بيانات حمولة ESP في وضع النقل الخاص برابطة SA مجردَ رسالةٍ لطبقةٍ أعلى مثل طبقة UDP أو TCP، فيعمل معيار IPsec في هذا الوضع بمثابة طبقة بروتوكول وسيطة، تمامًا مثل طبقة SSL / TLS الموجودة بين طبقة TCP وطبقةٍ أعلى، حيث تُمرَّر حمولة رسالة ESP عند تلقيها إلى بروتوكول المستوى الأعلى. لكن بيانات حمولة ESP في وضع النفق الخاص برابطة SA هي نفسها رزمة IP كما في الشكل الآتي، وقد يختلف مصدر ووجهة رزمة IP الداخلية عن مصدر ووجهة رزمة IP الخارجية. تُمرَر حمولة رسالة ESP عند تلقيها مثل رزمة IP عادية، والطريقة الأكثر شيوعًا لاستخدام بروتوكول ESP هي بناء "نفق IPsec" بين موجّهَين، أو عادةً بين جدران الحماية، حيث يمكن لشركةٍ على سبيل المثال ترغب في ربط موقعين باستخدام الإنترنت فتح زوجٍ من روابط SA في وضع النفق بين موجّهٍ router في موقع وموجّهٍ في الموقع الآخر، وقد تصبح رزمةُ IP الصادرة من أحد المواقع على الموجّه الصادر، حمولةَ رسالة ESP المرسلة إلى الموجه الخاص بالموقع الآخر، وهنا يفك الموجه المستقبِل غلاف حمولة رزمة IP ويمررها إلى وِجهتها الحقيقية. يمكن أيضًا ضبط هذه الأنفاق لاستخدام بروتوكول ESP مع خصوصيةٍ واستيثاق، وبالتالي منع الوصول غير المصرَّح به إلى البيانات التي تعبر هذا الرابط الوهمي، وضمان عدم تلقي أي بياناتٍ زائفةٍ في الطرف البعيد من النفق؛ كما يمكن للأنفاق أيضًا توفير خصوصية لحركة المرور، نظرًا لأن دمج التدفقات المتعددة عبر نفقٍ واحد يحجب معلومات مقدار حركة المرور التي تتدفق بين نقاط نهاية معينة. من الممكن استخدام شبكةٍ من هذه الأنفاق لتنفيذ شبكةٍ وهميةٍ خاصة virtual private network أو اختصارًا VPN كاملة، فلا يحتاج المضيفون الذين يتواصلون عبر شبكة VPN حتى أن يدركوا وجودها. الأمن اللاسلكي باستخدام معيار 802.11i تتعرض الروابط اللاسلكية للتهديدات الأمنية بسبب عدم وجود أي أمنٍ مادي على وسط الاتصال medium، وقد دفعت ملاءمة معيار 802.11 إلى قبولٍ واسع النطاق، ولكن كان الافتقار إلى الأمن مشكلةً متكررة، فمن السهل جدًا على موظف شركة مثلًا توصيل نقطة وصول 802.11 بشبكة الشركة، حيث تمر موجات الراديو عبر معظم الجدران؛ فإذا كانت نقطة الوصول تفتقر إلى تدابير الأمن الصحيحة، فيمكن للمهاجم الآن الوصول إلى شبكة الشركة من خارج المبنى؛ ويمكن لحاسوبٍ به محوّل adaptor شبكةٍ لاسلكية داخل المبنى الاتصال بنقطة وصولٍ خارج المبنى، مما قد يعرضه للهجوم، ناهيك عن بقية شبكة الشركة إذا كان هذا الحاسوب نفسه لديه اتصال إيثرنت أيضًا. وبالتالي كان هناك عملٌ كبيرٌ على تأمين روابط Wi-Fi، حيث تبيّن أن إحدى تقنيات الأمن القديمة التي طُوِّرت لمعيار 802.11، والمعروفة باسم الخصوصية المكافئة للشبكات السلكية Wired Equivalent Privacy أو اختصارًا WEP، مَعيبةٌ بصورةٍ خطيرة ويمكن كسرها بسهولةٍ تامة. يوفّر معيار IEEE 802.11i الاستيثاق وسلامة الرسائل والخصوصية لمعيار 802.11 "Wi-Fi" في طبقة الربط، حيث تُستخدَم تقنية الوصول المحمي للشبكات الحاسوبية رقم 3 Wi-Fi Protected Access 3 أو اختصارًا WPS 3، مثل مرادفٍ للمعيار 802.11i، على الرغم من أنها من الناحية الفنية علامةٌ تجاريةٌ لتحالف Wi-Fi الذي يشهد اتباع المنتج للمعيار 802.11i. يشمل معيارُ 802.11i تعريفاتٍ لخوارزميات الأمن من الجيل الأول للتوافق مع الإصدارات السابقة، بما في ذلك خوارزمية WEP التي بها عيوب أمنيةٌ كبيرة، لذلك سنركز هنا على خوارزميات معيار 802.11i الأحدث والأقوى. ويدعم استيثاق معيار 802.11i وضعين، حيث تكون النتيجة النهائية للاستيثاق الناجح في أيٍّ من الوضعَين هي مفتاحٌ مشترك رئيسي ثنائي. أولًا، يوفّر الوضع الشخصي Personal mode والمعروف أيضًا باسم وضع المفتاح المشترك المسبق Pre-Shared Key أو اختصارًا PSK أمنًا أضعف، ولكنه أكثر ملاءمةً واقتصادًا في مواقفٍ متعددة مثل شبكة 802.11 المنزلية، حيث يُضبط الجهاز اللاسلكي ونقطة الوصول Access Point أو اختصارًا AP مسبقًا باستخدام عبارة مرور passphrase مشتركة، وهي كلمة مرورٍ طويلة جدًا، ويُشتَق المفتاح الرئيسي الثنائي منها بطريقةٍ مشفَّرة. ثانيًا، يعتمد وضع الاستيثاق الأقوى لمعيار 802.11i على إطار العمل IEEE 802.1X بهدف التحكم في الوصول إلى شبكة LAN، والتي تستخدم خادم استيثاق AS كما في الشكل الآتي، حيث يجب توصيل خادم الاستيثاق AS ونقطة الوصول AP بواسطة قناةٍ آمنةٍ، ويمكن حتى تطبيقهما على أنهما صندوقٌ واحد، لكنهما منفصلان منطقيًا، حيث تمرّر نقطة الوصول AP رسائل الاستيثاق بين الجهاز اللاسلكي والخادم AS، ويُسمى البروتوكول المستخدم للاستيثاق بـبروتوكول الاستيثاق الموسَّع Extensible Authentication Protocol أو اختصارًا EAP، وقد صُمِّم لدعم أساليب الاستيثاق المتعددة، مثل البطاقات الذكية ونظام كيربيروس Kerberos وكلمات المرور لمرةٍ واحدة والاستيثاق بالمفتاح العام وغير ذلك، بالإضافة إلى الاستيثاق من جانبٍ واحد والاستيثاق المتبادل، لذلك من الأفضل التفكير في بروتوكول EAP مثل إطار عملٍ للاستيثاق بدلًا من عدّه بروتوكولًا. وتُسمى البروتوكولات المحددة المتوافقة مع بروتوكول EAP والتي يوجد العديد منها بأساليب EAP، فعلى سبيل المثال أسلوب EAP-TLS هو أسلوب EAP يعتمد على استيثاق TLS. لا يضع معيار 802.11i قيودًا على ما يمكن أن يستخدمه أسلوب EAP مثل أساسٍ للاستيثاق، ولكنه يحتاج أسلوب EAP لإجراء استيثاقٍ متبادل، لأننا لا نريد فقط منع خصم من الوصول إلى الشبكة عبر نقطة الوصول الخاصة بنا، بل نريد أيضًا منع الخصم من خداع أجهزتنا اللاسلكية بنقطة وصول خبيثة مزيفة. النتيجة النهائية للاستيثاق الناجح هي مفتاح ثنائي رئيسي Pairwise Master Key مشترك بين الجهاز اللاسلكي وخادم AS، والذي ينقله خادم AS بعد ذلك إلى نقطة الوصول. أحد الاختلافات الرئيسية بين الوضع الأقوى المستند إلى خادم AS والوضع الشخصي الأضعف، هو أن الأول يدعم بسهولة مفتاحًا فريدًا لكل عميل، وهذا بدوره يجعل من السهل تغيير مجموعة العملاء الذين يمكنهم استيثاق أنفسهم لإبطال الوصول إلى عميل مثلًا، وذلك دون الحاجة إلى تغيير السر المخزَّن في كل عميل. ينفّذ الجهاز اللاسلكي ونقطة الوصول AP بروتوكول إنشاء مفتاح جلسة يسمى المصافحة الرباعية لتأسيس مفتاحٍ انتقالي ثنائي Pairwise Transient Key مع وجود مفتاحٍ رئيسي ثنائي في متناولنا. هذا المفتاح الانتقالي الثنائي هو مجموعةٌ من المفاتيح المتضمنة مفتاح جلسةٍ يُسمى المفتاح المؤقت Temporal Key، حيث يُستخدَم مفتاح الجلسة هذا بواسطة البروتوكول المسمَّى CCMP الذي يوفر خصوصية وسلامة بيانات المعيار 802.11i. يرمز CCMP إلى وضع العدّاد Counter Mode -أو اختصارًا CTR- مع بروتوكول شيفرة استيثاق رسالة، مع تسلسل الكتل المشفَّرة Cipher-Block Chaining with Message Authentication Code أو اختصارًا CBC-MAC، والذي يستخدم خوارزمية AES في وضع العدّاد للتشفير من أجل الخصوصية. تذكر أنه في تشفير وضع العدّاد، تُدمج القيم المتتالية للعدّاد في تشفير الكتل المتتالية من النص الأصلي. يستخدم بروتوكول CCMP شيفرة استيثاق الرسالة Message Authentication Code -أو اختصارًا MAC- على أنها مستوثق، حيث تعتمد خوارزمية MAC على سلسلة CBC، على الرغم من أن بروتوكول CCMP لا يستخدم سلسلة CBC في تشفير الخصوصية. وتُطبَّق سلسلة CBC بدون إرسال أي من كتل CBC المشفَّرة، بحيث يمكن فقط استخدام آخر كتلة CBC مشفرة مثل شيفرة MAC، ويُستخدَم فعليًا أول 8 بايتات فقط. تلعب أول كتلةٍ مصممة بصورةٍ خاصة دورَ متجه التهيئة، وتتضمن هذه الكتلة رقم رزمةٍ مؤلفٍ من 48 بتًا؛ وهو رقمٌ تسلسلي مُضمَّنٌ أيضًا في تشفير الخصوصية، ويعمل على كشف هجمات إعادة الإرسال. تُشفَّر شيفرة MAC لاحقًا مع النص الأصلي من أجل منع هجمات عيد الميلاد birthday attacks، والتي تعتمد على العثور على رسائل مختلفة باستخدام نفس المستوثق. جدران الحماية Firewalls ركّزت هذه السلسلة في هعلى استخدامات التشفير لتوفير ميزات الأمن مثل الاستيثاق والخصوصية، لكن هناك مجموعةٌ كاملةٌ من مشكلات الأمن التي لا تُعالَج بسهولة بوسائل التشفير؛ حيث تنتشر الديدان worms والفيروسات viruses عن طريق استغلال الأخطاء في أنظمة التشغيل والبرامج التطبيقية، وأحيانًا السذاجة البشرية أيضًا، ولا يمكن لأي قدرٍ من التشفير أن يساعدك إذا كان جهازك به ثغرات أمنية لم تُصلَح، لذلك غالبًا تُستخدَم أساليبٌ أخرى لمنع الأشكال المختلفة من حركة المرور التي قد تكون ضارة. وتُعد جدران الحماية من أكثر الطرق شيوعًا لذلك. جدار الحماية هو نظامٌ يُوضَع عادةً في نقطةٍ ما من الاتصال بين موقع يحميه وبقية الشبكة، كما هو موضحٌ في الشكل الآتي: حيث يُطبّق جدار الحماية عادةً على أنه "جهاز" أو جزءٌ من موجّه، على الرغم من أنه يمكن تطبيق "جدار حمايةٍ شخصي" على جهاز المستخدم النهائي. ويعتمد الأمن المستند إلى جدار الحماية على كونه وسيلة الاتصال الوحيدة بالموقع من الخارج، حيث يجب ألا تكون هناك طريقةٌ لتجاوز جدار الحماية عبر بواباتٍ أخرى أو اتصالاتٍ لاسلكية أو اتصالات الطلب الهاتفي. يُعَد استخدام استعارة الجدار أمرًا مضللًا إلى حدٍ ما في سياق الشبكات، لأن قدرًا كبيرًا من حركة المرور تمر عبر جدار الحماية، وتتمثل إحدى طرق التفكير في جدار الحماية في أنه يحظر افتراضيًا حركة المرور ما لم يُسمح لهذه الحركة على وجه التحديد بالمرور خلاله، فقد يصفّي جميعَ الرسائل الواردة باستثناء تلك العناوين لمجموعةٍ معينة من عناوين IP أو لأرقام منافذ TCP معينة على سبيل المثال. يقسم جدار الحماية الشبكة إلى منطقةٍ أكثر وثوقية داخل جدار الحماية ومنطقةٍ أقل وثوقية خارج جدار الحماية، ويكون هذا مفيدًا إذا لم ترغب في وصول المستخدمين الخارجيين إلى مضيفٍ أو خدمةٍ معينة داخل موقعك. يأتي الكثير من التعقيد من حقيقة أنك تريد السماح بأنواع وصولٍ مختلفة إلى مستخدمين خارجيين مختلفين، بدءًا من عامة الناس، إلى شركاء العمل، وحتى أعضاء مؤسستك عن بُعد. كما قد يفرض جدار الحماية أيضًا قيودًا على حركة المرور الصادرة لمنع هجماتٍ معينة والحد من الخسائر إذا نجح أحد الخصوم في الوصول إلى داخل جدار الحماية. يكون موقع جدار الحماية غالبًا هو الخط الفاصل بين المناطق القابلة للتوجيه عالميًا وتلك التي تستخدم العناوين المحلية، وتكون وظيفة ترجمة عناوين الشبكة Network Address Translation -أو اختصارًا NAT- ووظيفة جدار الحماية موجودة ًعلى نفس الجهاز، على الرغم من أنهما وظيفتان منفصلتان منطقيًا. يمكن استخدام جدران الحماية لإنشاء مناطق ثقة zones of trust متعددة، مثل تسلسلٍ هرمي للمناطق الموثوق بها بصورةٍ متزايدة. ويتضمن الترتيب الشائع ثلاث مناطق ثقة هي الشبكة الداخلية، والمنطقة "منزوعة السلاح" demilitarized zone -أو اختصارًا DMZ-، وبقية شبكة الإنترنت. تُستخدَم منطقة DMZ للاحتفاظ بخدماتٍ مثل خوادم DNS والبريد الإلكتروني التي تحتاج إلى الوصول إليها من الخارج، حيث يمكن لكلٍ من الشبكة الداخلية والعالم الخارجي الوصول إلى منطقة DMZ، لكن المضيفين في منطقة DMZ لا يمكنهم الوصول إلى الشبكة الداخلية؛ لذلك لا يزال الخصم الذي ينجح في اختراق مضيف في منطقة DMZ المكشوفة غير قادرٍ على الوصول إلى الشبكة الداخلية، ويمكن إعادة منطقة DMZ دوريًا إلى الحالة النظيفة clean state. تصفّي جدران الحماية حركة المرور بناءً على معلومات بروتوكولات IP وTCP وUDP، وتُضبَط باستخدام جدول عناوين يميّز الرزم التي ستُمرّر عن تلك غير المُمررة، ونعني بالعناوين أكثر من مجرد عنوان IP الوجهة، على الرغم من أن هذا أحد الاحتمالات. تكون كل مدخلةٍ في الجدول مؤلَّفةً من مجموعةٍ لها 4 قيم هي عنوان IP ورقم منفذ TCP أو UDP لكلٍ من المصدر والوِجهة. قد يُضبَط جدار حماية لتصفية وليس تمرير جميع الرزم التي تطابق الوصف التالي على سبيل المثال: (192.12.13.14, 1234, 128.7.6.5, 80) يشير هذا النمط إلى تجاهل جميع الرزم من المنفذ 1234 على المضيف ذي العنوان 192.12.13.14، والموجَّهة إلى المنفذ 80 على المضيف ذي العنوان 128.7.6.5، حيث أن المنفذ 80 هو منفذ TCP معروف لبروتوكول HTTP. تكون تسمية كل مضيف مصدر تريد تصفية رزمه أمرًا غير عملي غالبًا، لذلك يمكن أن تتضمن الأنماط أحرف البدل wildcards. فمثلًا يشير ما يلي إلى تصفية جميع الرزم الموجّهة إلى المنفذ 80 على المضيف 128.7.6.5، بغض النظر عن مصدر المضيف أو المنفذ الذي أرسل الرزمة. (*, *, 128.7.6.5, 80) لاحظ أن نمطًا مثل هذه العناوين يتطلب جدار حماية لاتخاذ قرارات التمرير أو التصفية بناءً على أرقام منافذ المستوى 4، بالإضافة إلى عناوين المضيف من المستوى 3، ولهذا السبب تسمى جدران حماية طبقة الشبكة أحيانًا مبدّلات المستوى 4. يمرر جدار الحماية في المناقشة السابقة كل شيء باستثناء ما يُطلب منه تحديدًا لتصفية أنواعٍ معينة من الرزم، ويمكن لجدار الحماية أيضًا تصفية كل شيء ما لم تصدر تعليمات صريحة بتمريرها، أو استخدام مزيجٍ من الاستراتيجيتين، فبدلًا من حظر الوصول إلى المنفذ 80 على المضيف 128.7.6.5، قد يُوجَّه جدار الحماية للسماح فقط بالوصول إلى المنفذ 25 وهو منفذ بريد بروتوكول SMTP على خادم بريدٍ معين وذلك لمنع كل حركة المرور الأخرى كما يلي: (*, *, 128.19.20.21, 25) أظهرت التجربة أن جدران الحماية تُضبَط بصورةٍ متكررة بطريقةٍ غير صحيحة، مما يسمح بالوصول غير الآمن؛ حيث يتمثل جزءٌ من المشكلة في امكانية تداخل قواعد التصفية بطرقٍ معقدة، مما يجعل من الصعب على مسؤول النظام التعبير عن التصفية المقصودة بصورةٍ صحيحة. ويعتمد مبدأ التصميم الذي يزيد مستوى الأمن، على ضبط جدار حماية لتجاهل جميع الرزم بخلاف تلك المسموح بها صراحة؛ وهذا يعني أن بعض التطبيقات الصالحة قد تُعطَّل عن طريق الخطأ، فيُفترَض أن يلاحظ مستخدمو هذه التطبيقات في النهاية ذلك، ويطلبون من مسؤول النظام إجراء التغيير المناسب. تُسنِد العديد من تطبيقات العميل / الخادم منفذًا للعميل ديناميكيًا، فإذا بدأ عميلٌ داخل جدار الحماية بالوصول إلى خادمٍ خارجي، فستُوجَّه استجابة الخادم إلى المنفذ المُسنَد ديناميكيًا. يطرح ذلك مشكلةً هي: كيف يمكن ضبط جدار الحماية للسماح بمرور رزمة استجابة خادمٍ عشوائية دون السماح بمرور رزمةٍ طلبٍ مماثلة لم يطلبها العميل؟ هذا غير ممكنٍ مع جدار حماية عديم الحالة stateless firewall يقيّم كل رزمةٍ على حدة، فهذا يتطلب وجود جدار حمايةٍ ذو حالة stateful firewall يتتبّع حالة كلّ اتصال، وعندئذٍ سيُسمَح للرزمة الواردة الموجَّهة إلى منفذٍ مُسنَدٍ ديناميكيًا بالمرور فقط إذا كانت هذه الرزمة استجابةً صالحةً في حالة الاتصال الحالية على ذلك المنفذ. تفهم جدران الحماية الحديثة وتصفّي أيضًا بناءً على العديد من البروتوكولات المحددة على مستوى التطبيق مثل بروتوكولات HTTP أو Telnet أو FTP، وتستخدم معلوماتٍ خاصة بهذا البروتوكول، مثل عناوين URL في حالة بروتوكول HTTP، لاتخاذ قرار تجاهل الرسالة أم لا. نقاط القوة والضعف في جدران الحماية يحمي جدار الحماية الشبكة من الوصول غير المرغوب فيه من بقية الإنترنت في أحسن الأحوال، حيث لا يمكنه توفير الأمن للاتصال المشروع بين داخل وخارج جدار الحماية؛ وتستطيع في المقابل آليات الأمن القائمة على التشفير الموضَّحة في هذا الفصل توفير اتصالٍ آمنٍ بين المشاركين في أي مكان. لكن لماذا تكون جدران الحماية شائعةً جدًا في هذه الحالة؟ أحد الأسباب هو امكانية نشر جدران الحماية من جانبٍ واحد باستخدام منتجات تجارية ناضجة، بينما يتطلب الأمن المستند إلى التشفير دعمًا عند نقطتي نهاية الاتصال؛ والسبب الأكثر جوهريةً لهيمنة جدران الحماية، هو أنها تغلّف الأمن في مكانٍ مركزي، مما يؤدي في الواقع إلى استبعاد الأمن من بقية الشبكة، حيث يمكن لمسؤول النظام إدارة جدار الحماية لتوفير الأمن وتحرير المستخدمين والتطبيقات داخل جدار الحماية من مخاوف الأمن أو من بعض أنواع المخاوف الأمنية على الأقل. جدران الحماية لها قيودٌ خطيرة، فيمكن للخصم الذي يدير تشغيل تعليمات الموقع البرمجية الداخلية الوصول إلى جميع المضيفين المحليين، نظرًا لأن جدار الحماية لا يقيّد الاتصال بين المضيفين الموجودين داخل جدار الحماية. لكن كيف يمكن لخصمٍ الدخول إلى داخل جدار الحماية؟ قد يكون الخصم موظفًا غاضبًا يملك إذنًا بالوصول الشرعي، أو قد يُخفى برنامج الخصم ضمن بعض البرامج المثبَّتة من قرصٍ مضغوط أو من خلال تنزيلها من الويب، حيث من الممكن تجاوز جدار الحماية باستخدام الاتصالات اللاسلكية أو اتصالات الطلب الهاتفي dial-up connections. قد تصبح مشكلةً أخرى ثغرةً أمنية، وهي منح أيٍّ من الأطراف إمكانية الوصول من خلال جدار الحماية الخاص بك، مثل شركاء العمل أو الموظفين الموجودين في الخارج، فإذا لم يكن أمن هؤلاء الأطراف جيدًا مثل أمنك، فيمكن للخصم اختراق أمنك من خلال اختراق أمنهم. من أخطر المشاكل التي تواجه جدران الحماية هي قابليتها للتأثر باستغلال الأخطاء في الأجهزة الموجودة داخل جدار الحماية، حيث تُكتشَف مثل هذه الأخطاء بانتظام، لذلك يجب على مسؤول النظام مراقبة الإعلانات عنها باستمرار. يفشل المسؤولون في كثيرٍ من الأحيان بمراقبة ذلك، نظرًا لاستغلال الانتهاكات الأمنية لجدار الحماية الثغرات الأمنية التي كانت معروفةً لبعض الوقت ولديها حلولٌ مباشرة. يشير مصطلح البرامج الضارة Malware أو "malicious software" إلى البرامج المصممة للعمل على الحاسوب بطرقٍ خفيّة عن مستخدمه وغير مرغوبٍ بها، وتُعَد الفيروسات والديدان وبرامج التجسس أنواعًا شائعةً من البرامج الضارة، حيث تُستخدَم الفيروسات مرادفًا ببعض الأحيان للبرامج الضارة، ولكننا سنستخدمها بالمعنى الضيق، حيث تشير فقط إلى نوعٍ معين من البرامج الضارة. لا يلزم أن تكون شيفرة البرامج الضارة شيفرةَ كائن قابلٍ للتنفيذ محليًا، كما يمكن أن تكون شيفرةً مُفسَّرة مثل نصٍ برمجي أو ماكرو macro قابلًا للتنفيذ مثل تلك االشيفرة المستخدَمة بواسطة برنامج Microsoft Word. تتميز الفيروسات والديدان بالقدرة على صنع نسخٍ من نفسها ونشرها؛ فالفرق بينها هو أن الدودة هي برنامجٌ كامل ينسخ نفسه، بينما الفيروس هو جزءٌ من الشيفرة الذي يجري إدخاله وإدراج نسخٍ منه في جزءٍ آخر من البرنامج أو الملف، بحيث يُنفَّذ مثل جزءٍ من تنفيذ هذا البرنامج أو نتيجةٍ لفتح الملف. تسبّب الفيروسات والديدان مشاكلًا في استهلاك حيز نطاق الشبكة التراسلي مثل أثرٍ جانبي لمحاولة نشر نسخٍ منها، ويمكنها أيضًا إتلاف النظام عمدًا أو تقويض أمنه بطرقٍ مختلفة؛ كما يمكنها تثبيت بابٍ خلفي backdoor مخفي على سبيل المثال، وهو برنامجٌ يسمح بالوصول البعيد إلى النظام دون استخدام الاستيثاق العادي، وقد يؤدي ذلك إلى كشف جدار الحماية الخدمةََ التي يجب أن توفر إجراءات الاستيثاق الخاصة بها ولكنها قُوضت بسبب الباب الخلفي. برامج التجسس Spyware هي برامجٌ تجمع وتنقل معلوماتٍ خاصة عن نظام الحاسوب أو مستخدميه بدون تصريح، حيث تُضمَّن سرًا في برنامجٍٍ مفيد مختلف، وينشرها المستخدمون عن عمد عن طريق تثبيت نُسخٍ منه. تكمن مشكلة جدران الحماية في أن إرسال المعلومات الخاصة يبدو كأنه اتصال شرعي. السؤال الواجب طرحه هو ما إذا كان لجدران الحماية أو أمن التشفير القدرة على منع دخول البرامج الضارة إلى النظام في المقام الأول، حيث تُنقل معظم البرامج الضارة فعليًا عبر الشبكات، ويمكن نقلها أيضًا عبر أجهزة التخزين المحمولة مثل الأقراص المضغوطة وشرائح الذاكرة، ويُعَد ذلك حجةً لصالح نهج "حظر كل شيء غير مسموحٍ به صراحةً"، والذي يتّبعه العديد من المسؤولين في ضبط جدار الحماية الخاص بهم. أحد الأساليب المستخدمة لاكتشاف البرامج الضارة هو البحث عن أجزاء شيفرة البرامج الضارة المعروفة المُسماة أحيانًا التوقيع signature. هذا النهج له تحدياته الخاصة، حيث يمكن للبرامج الضارة المصمَّمة بذكاء تعديل تمثيلها بطرقٍ مختلفة؛ وهناك أيضًا تأثيرٌ محتمل على أداء الشبكة لإجراء مثل هذا الفحص التفصيلي للبيانات التي تدخل الشبكة، فلا يمكن لأمن التشفير القضاء على المشكلة أيضًا، على الرغم من أنه يوفّر وسيلةً لاستيثاق منشئ البرنامج واكتشاف أي تلاعب، مثل إدخال فيروسٍ نسخةً منه. ترتبط بجدران الحماية أنظمةٌ تُعرف باسم أنظمة كشف التسلل intrusion detection systems -أو اختصارًا IDS- وأنظمة منع التطفل intrusion prevention systems -أو اختصارًا IPS-، حيث تحاول هذه الأنظمة البحث عن نشاطٍ غير طبيعي، مثل وجود كميةٍ كبيرة بصورةٍ غير عادية من حركة المرور التي تستهدف مضيفًا معينًا أو رقم منفذٍ معين، وتوليد إنذارات لمديري الشبكة، أو ربما اتخاذ إجراءٍ مباشر للحد من هجومٍ محتمل. هناك منتجات تجارية في هذا المجال اليوم، ولكنه لا يزال مجالًا قيد التطوير. سلسلة الكتل Blockchain والإنترنت اللامركزي ربما وضع المستخدمون جزءًا كبيرًا من ثقتهم في التطبيقات التي يستخدمونها دون التفكير في الأمر كثيرًا، خاصةً في تطبيقات مثل فيسبوك وجوجل التي لا تخزّن فقط الصور ومقاطع الفيديو الشخصية الخاصة بهم، ولكنها أيضًا تدير هوياتهم أي توفّر تسجيل الدخول الموحَّد لتطبيقات الويب الأخرى. هذا أمرٌ مزعج لكثيرٍ من الناس، مما أثار الاهتمام بالمنصات اللامركزية decentralized platforms، أي الأنظمة التي لا يتعيّن على المستخدمين الوثوق بطرفٍ ثالث، حيث تعتمد مثل هذه الأنظمة على عملةٍ مشفّرة مثل بيتكوين Bitcoin، ليس لقيمتها النقدية، ولكن لاعتماد العملة المشفَّرة في حد ذاتها على تقنيةٍ لامركزية تُسمى سلسلة الكتل blockchain والتي لا تتحكم فيها أية مؤسسة وهي في الأساس سجلٌ لامركزي ledger يمكن لأي شخصٍ كتابة "حقيقةٍ" فيه، ثم يثبت للعالم فيما بعد أن هذه الحقيقة سُجِّلت. تطبيق بلوكستاك Blockstack هو تطبيقٌ مفتوح المصدر لمنصةٍ لا مركزية مثل سلسلة الكتل، وقد اُستخدِم لتطبيق خدمة الهوية ذات السيادة الذاتية لتطبيقات الإنترنت self-sovereign identity service؛ وهي نوعٌ من خدمات الهوية اللامركزية إداريًا، أي ليس لديها مشغّل خدمةٍ مميز، ولا يوجد مدير يمكنه التحكم فيمَن يمكنه إنشاء هوية ومَن لا يستطيع. يستخدم تطبيق Blockstack سلسلة كتلٍ سلعيةٍ عامة لإنشاء سجل قاعدة بيانات هويات مضاعف، وينتج عن إعادة تشغيل سجل قاعدة البيانات بواسطة عقدة Blockstack لجميع هويات النظام التي تظهر مثل سلسلة الكتل الأساسية التي تراها كل عقدة Blockstack أخرى، حيث يمكن لأي شخصٍ تسجيل هويةٍ في تطبيق Blockstack من خلال إلحاقها بسلسلة الكتل. يطلب بروتوكول هويات تطبيق Blockstack من المستخدمين الوثوق في أن غالبية عُقد اتخاذ القرار في سلسلة الكتل (يطلق على هذه الكتل اسم miners) ستحافظ على ترتيب عمليات الكتابة المُسماة معامَلات transactions، بدلًا من مطالبة المستخدمين بوضع الثقة في مجموعةٍ متميزة من موفّري الهوية، حيث توفّر سلسلة الكتل الأساسية عملةً مشفَّرةً لتحفيز عقد miners لفعل ذلك. ويمكن لعقد miners في ظل التشغيل العادي أن تربح أكبر عددٍ من العملات المشفرة من خلال المشاركة بأمانة، ويسمح هذا لسجل قاعدة بيانات Blockstack بالبقاء آمنًا ضد العبث بدون مشغّل خدمةٍ مميز. ويجب أن يتنافس الخصم الذي يرغب في التلاعب بالسجل مع غالبية عقد miners لإنتاج سجل معاملاتٍ بديل ضمن سلسلة الكتل الأساسية التي تقبله شبكة نظراء سلسلة الكتل على أنه سجل كتابةٍ معترفٍ به. يعمل بروتوكول قراءة وإلحاق سجل قاعدة بيانات هوية Blockstack ضمن طبقةٍ منطقية على سلسلة الكتل، وتُعَد معامَلات سلسلة الكتل إطارات بياناتٍ خاصةٍ بمدخلات سجل قاعدة بيانات الهويات، حيث يُلحق العميل بسجل قاعدة بيانات الهويات من خلال إرسال معامَلة transaction سلسلة كتل تتضمن مدخلة سجل قاعدة البيانات، ويقرأ العميل السجل مرةً أخرى عن طريق استخراج مدخلات السجل من معامَلات سلسلة الكتل بالترتيب المحدد لهذه السلسلة. يؤدي هذا إلى إمكانية تطبيق سجل قاعدة بيانات "أعلى" من أية سلسلة كتل. تُميَّز الهويات في تطبيق Blockstack بأسماءٍ يختارها المستخدم، إذ يربط بروتوكول هويات تطبيق Blockstack كل اسمٍ بمفتاحٍ عام وببعض حالات التوجيه الموضَّحة أدناه، ويضمن أن تكون الأسماء فريدة عالميًا من خلال إسنادها على أساس من يأتي أولًا يخدَّم أولًا first-come first-serve. تُسجَّل الأسماء في عمليةٍ مكونة من خطوتين، حيث تُستخدَم الخطوة الأولى لربط مفتاح العميل العام بقيمة الاسم المُعمَّاة ذات الغُفل salted hash؛ والتي هي بيانات عشوائية تُستخدم كأنها دخلٌ إضافي لوظيفةٍ أحادية الاتجاه مثل القيمة المُعمَّاة، وتُستخدَم الخطوة الأخرى لكشف الاسم نفسه. تُعَد العملية المكونة من خطوتين ضروريةً لمنع التشغيل الأمامي front-running، حيث قد يكشف العميل الذي وقّع على قيمة الاسم المُعمَّاة فقط عن هذا الاسم، ويمكن للعميل الذي حسَب القيمة المُعمَّاة ذات الغُفل فقط الكشف عن الصورة الأولية preimage، وبمجرد تسجيل الاسم يمكن فقط لمالك مفتاح الاسم الخاص نقل الاسم أو إبطاله أو تحديث حالة التوجيه الخاصة به. يحتوي كل اسمٍ في تطبيق Blockstack على جزءٍ من حالة التوجيه المرتبطة به، والتي تحتوي على عنوانٍ أو أكثر من عناوين URL التي تشير إلى مكان العثور على معلومات هوية المستخدم عبر الإنترنت. هذه البيانات كبيرة جدًا ومكلفة جدًا، بحيث لا يمكن تخزينها على سلسلة كتلٍ مباشرةً، لذلك يطبِّق Blockstack بدلًا من ذلك طبقةً من المخادعة، حيث تُكتَب قيمة حالة التوجيه المُعمَّاة في سجل قاعدة بيانات الهويات، وينفّذ نظراء تطبيق Blockstack شبكة نشر الشائعات gossip network لنشر واستيثاق حالة التوجيه، ويحتفظ كل نظير بنسخةٍ كاملة من حالة التوجيه. يوضّح الشكل السابق كيفية ربط كل اسمٍ مع حالة الهوية المقابلة له، حيث يستعلم العميل أولًا عند إعطائه اسمًا عن نظير تطبيق Blockstack للمفتاح العام المقابل وحالة التوجيه (الخطوة 1)، ثم يحصل العميل بعد امتلاكه حالة التوجيه على بيانات الهوية من خلال ربطها بعنوان (أو عناوين) URL الموجود بداخله ويستوثق معلومات الهوية عن طريق التحقق من توقيعها بواسطة مفتاح الاسم العام (الخطوة 2). ترجمة -وبتصرّف- للقسم Example Systems من فصل Network Security من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: مفتاح التوزيع المسبق وبروتوكولات الاستيثاق المستخدمة في أمن الشبكات الحاسوبية الهجمات الأمنية Security Attacks في الشبكات الحاسوبية تأمين الشبكات تأمين الشبكات اللاسلكية مقدمة في تأمين خادوم لينكس كيفية تأمين الخواديم السحابية ضد هجمات حقن SQL النسخة الكاملة من كتاب دليل الأمان الرقمي

شبكات الحاسوب موردٌ مشترك تستخدمه العديد من التطبيقات المختلفة، حيث تجري مشاركة شبكة الإنترنت على نطاقٍ واسع، فتستخدمها الشركات المتنافسة والحكومات المتخاصمة والمجرمون الانتهازيون، وقد يخترق خصمك محادثاتك عبر الشبكة أو يخترق تطبيقًا موزَّعًا في حال عدم اتخاذ تدابيرٍ أمنية. افترض على سبيل المثال وجود بعض التهديدات لأمان استخدام الويب، وافترض أنك عميلٌ يستخدم بطاقة ائتمان لطلب عنصرٍ من موقع ويب. هنا سيكون التهديد الواضح هو أن الخصم قد يتنصت على اتصالات شبكتك، ويقرأ رسائلك للحصول على معلومات بطاقتك الائتمانية، لكن كيف يمكن تحقيق هذا التنصت؟ إنه أمرٌ بسيط على شبكة بثٍ عام مثل شبكة إيثرنت Ethernet أو شبكة Wi-Fi، حيث يمكن ضبط أي عقدةٍ لتلقي كل حركة مرور الرسائل على تلك الشبكة. تتضمن الأساليب الأخرى الأكثر توسعًا التنصت على المكالمات الهاتفية وزرع برمجيات تجسس على أية سلسلةٍ من العقد. تُتخَّذ تدابيرٌ جادة فقط في الحالات القصوى مثل الأمن القومي لمنع مثل هذه المراقبة، ولكن شبكة الإنترنت ليست واحدةً من تلك الحالات، ولكن يمكن عمليًا تشفير الرسائل لمنع الخصم من فهم محتويات الرسالة، حيث نقول عن البروتوكول الذي يؤمن بذلك أنه يوفّر الخصوصية confidentiality. إذا أخذنا هذا المفهوم خطوةً لمستوى آخر مع إخفاء كمية الاتصال أو وجهته، فيُسمَّى ذلك خصوصية حركة المرور traffic confidentiality، حيث أن مجرد معرفة مقدار الاتصالات الجارية يمكن أن يكون مفيدًا للخصم في بعض المواقف. لكن لا تزال هناك تهديدات لعميل الموقع حتى مع وجود تلك الخصوصية، فقد يظل الخصم الذي لا يستطيع قراءة محتويات رسالتك المشفرة قادرًا على تغيير بعض البتات فيها، مما يؤدي إلى طلبٍ صالحٍ لعنصرٍ مختلف تمامًا على سبيل المثال، أو ربما طلب 1000 وحدةٍ من ذلك العنصر. هناك تقنيات لاكتشاف مثل هذا العبث على الأقل إذا لم تكن قادرةً على منعه، حيث يُقال عن البروتوكول الذي يكتشف هذا العبث في الرسائل بأنه يوفِّرسلامةَ البيانات integrity. هناك تهديدٌ آخر للعميل هو توجيهه دون معرفته إلى موقع ويب مزيف، حيث يمكن أن ينتج هذا عن هجوم نظام أسماء النطاقات Domain Name System أو اختصارًا DNS، حيث تُدخَل معلوماتٌ خاطئة في خادم DNS أو ذاكرة خدمة الأسماء المخبئية لحاسوب العميل، ويؤدي هذا إلى ترجمة عنوان URL الصحيح إلى عنوان IP غير صحيح (أي عنوان موقع ويب مزيف). يُقال عن البروتوكول الذي يضمن أنك تتحدث حقًا مع مَن تعتقد أنك تتحدث إليه بأنه يوفر الاستيثاق authentication، ويستلزم الاستيثاقُ سلامةَ البيانات، لأنه لا فائدة من رسالةٍ ما جاءت من مشاركٍ معين إن لم تكن هذه الرسالة هي نفسها. من الممكن مهاجمة مالك الموقع أيضًا، فقد شُوِّهت بعض المواقع الإلكترونية أكثر، خاصةً لما جرى الوصول عن بُعد إلى الملفات التي يتكوّن منها محتوى موقع الويب وتعديلها دون إذن، وهذه هي مشكلة التحكم في الوصول access control، أي فرض القواعد المتعلقة بمن يُسمَح له بفعل شيءٍ وبماذا يُسمَح له. لقد تعرّضت مواقع الويب أيضًا لهجمات حجب الخدمة denial of service أو اختصارًا DoS، والتي يتعذر خلالها على العملاء المحتملين الوصول إلى موقع الويب بسبب غمره بالطلبات الوهمية، أو ما يُسمى ضمان درجةٍ من الوصول بالتوافرية availability. لقد اُستخدِمت شبكة الإنترنت بصورةٍ ملحوظة مثل وسيلةٍ لنشر الشيفرات الضارة المُسماة البرامج الضارة malware، والتي تستغل الثغرات الأمنية في الأنظمة النهائية، كما عُرفت أيضًا الديدان Worms وهي أجزاءٌ من شيفرةٍ ذاتية النسخ تنتشر عبر الشبكات منذ عدة عقود وما زالت تسبب مشاكلًا، مثلها مثل الفيروسات viruses التي تنتشر عن طريق نقل الملفات المصابة. يمكن بعد ذلك ترتيب الأجهزة المصابة في شبكات الروبوتات المقرصنة botnets، والتي يمكن استخدامها لإلحاق المزيد من الضرر مثل شن هجمات حجب الخدمة DoS. الثقة والتهديدات يجب التأكيد على حقيقةٍ بسيطة واحدة قبل تناول كيفية وسبب بناء شبكاتٍ آمنة تمامًا، وهي أننا سنفشل حتمًا في تحقيق ذلك، لأن الأمن هو في نهاية المطاف ممارسةٌ لوضع افتراضاتٍ حول الثقة وتقييم التهديدات وتخفيف المخاطر، فلا يوجد شيء اسمه أمنٌ تام. الثقة والتهديد وجهان لعملةٍ واحدة، والتهديد هو سيناريو لفشلٍ محتمل تصمِّم نظامك لتجنبه؛ أما الثقة فهي افتراضٌ نضعه حول كيفية تصرّف الجهات الخارجية الفاعلة والمكونات الداخلية التي تبني عليها نظامك. فإذا أرسلت رسالةً عبر شبكة WiFi في حرمٍ جامعي مفتوح على سبيل المثال، فمن المحتمل أن تحدد متنصتًا يمكنه اعتراض الرسالة على أنه تهديد واعتماد بعض الأساليب المُناقَشة في هذا المقال مثل إجراءٍ مضاد، ولكن إذا كنت في خِضم إرسال رسالة خلال ليفٍ ضوئي fiber بين جهازين في مركز بيانات مغلق، فقد تثق بأن القناة آمنة ولا تتخذ أي خطواتٍ إضافية. بما أنك تملك فعليًا طريقةً لحماية الاتصالات القائمة على شبكة WiFi، فأنت تستخدم هذه الطريقة أيضًا لحماية القناة القائمة على الألياف، ولكن يجب تحليل نتيجة التكلفة مع الفائدة. على فرض أن حماية أية رسالةٍ سواءً كانت مُرسلةً عبر شبكة WiFi أو عبر الألياف تؤدي إلى إبطاء الاتصال بنسبة 10% بسبب حِمل التشفير الزائد، فإن احتمال اقتحام شخصٍ ما لمركز البيانات هي واحدٌ في المليون (وحتى لو فعل ذلك فإن البيانات المُرسَلة لها قيمة قليلة)؛ عندئذٍ سيكون لديك مبررٌ جيد لعدم تأمين قناة اتصال الألياف. تحدث هذه الأنواع من الحسابات طوال الوقت على الرغم من أنها ستكون غالبًا ضمنيةً وغير مذكورة، حيث يمكنك مثلًا تشغيل خوارزمية التشفير الأكثر أمانًا في العالم على رسالةٍ قبل إرسالها، لكنك ستثق ضمنيًا في أن الخادم الذي تعمل عليه ينفّذ هذه الخوارزمية بأمانة ولا يسرّب نسخةً من رسالتك غير المشفَّرة إلى الخصم. هل تتعامل مع ذلك على أنه تهديد أم أنك تثق في أن الخادم لا يسيء التصرف؟ أفضل ما يمكنك فعله هو التخفيف من المخاطر من خلال تحديد تلك التهديدات التي يمكنك القضاء عليها بطريقةٍ فعالةٍ من حيث التكلفة، وكن صريحًا بشأن افتراضات الثقة التي تأخذ بها حتى لا تُفاجَأ بتغير الظروف، مثل خصمٍ أكثر إصرارًا أو تطورًا. لقد أصبح التهديد في هذا المثال بالذات المتمثّل في مساومة compromising أحد الخصوم على الخادم أمرًا حقيقيًا تمامًا مع انتقال المزيد من حساباتنا من الخوادم المحلية إلى السحابة، ولذا فإن البحث الجاري الآن على بناء قاعدة حوسبة موثوقة Trusted Computing Base أو اختصارًا TCB هو موضوعٌ مهم ولكنه موجود ضمن مجال معمارية الحواسيب وليس ضمن مجال الشبكات الحاسوبية. نوصيك بالانتباه إلى مصطلحات الثقة trust والتهديد threat أو الخصم adversary، لأنها مفتاحٌ لفهم السياق الذي يجري فيه تقديم المطالب الأمنية. موّلت وزارةُ الدفاع الأمريكية شبكةَ الإنترنت وشبكةَ أربانت ARPANET قبلها، وهي منظمةٌ تتفهّم بالتأكيد تحليل التهديدات. وقد سيطرت على التقييم الأصلي مخاوفٌ بشأن صمود الشبكة في مواجهة فشل الموجّهات والشبكات، وهو ما يفسر سبب كون خوارزميات التوجيه لا مركزية، أي بِلا نقطة فشلٍ مركزية. افترضَ التصميم الأولي أن جميع الفاعلين داخل الشبكة موثوقٌ بهم، ولم يولِ اهتمامًا يذكر بما نسميه اليوم الأمن السيبراني cybersecurity، الذي يمثّل هجماتٍ من فاعلين سيئين قادرين على الاتصال بالشبكة. يعني ذلك أن العديد من الأدوات الموضّحة في هذا المقال يمكن عدها رقعًا patches؛ فالرقعة هي برنامجٌ مصمَّم لإصلاح المشاكل أو لتحديث برنامج حاسوبي أو البيانات الداعمة له، وهذا يشمل تحديد نقاط الضعف الأمنية والأخطاء الأخرى وتحسين قابليتها للاستخدام أو أدائها، فهذه الأدوات متأصلةٌ بقوة في علم التشفير، ولكنها تُعَد "إضافات add-ons". إذا أُجريت إعادة تصميمٍ شاملة للإنترنت، فمن المحتمل أن يكون دمج الأمن في شبكة الإنترنت هو الدافع الرئيسي لإعادة التصميم. كتل بناء التشفير Cryptographic Building Blocks نقدم مفاهيم الأمن المعتمد على التشفير خطوةً بخطوة، حيث تتتمثل الخطوة الأولى في خوارزميات التشفير أي الشيفرات ciphers والقيم المُعمَّاة المشفَّرة cryptographic hashes التي سنوضحها في هذا القسم، وهي ليست حلًا في حد ذاتها، بل هي لبِنات بناءٍ يمكن من خلالها بناء حل. تحدّد المفاتيح keys معاملات خوارزميات التشفير، وسنتكلم لاحقًا عن مشكلة توزيع المفاتيح. سنشرح كيفية دمج كتل بناء التشفير في البروتوكولات التي توفّر اتصالًا آمنًا بين المشاركين الذين يمتلكون المفاتيح الصحيحة، ثم نختبر عدة بروتوكولات وأنظمة أمنية كاملة قيد الاستخدام حاليًا. مبادئ الشيفرات يحوّل التشفير Encryption الرسائل بطريقةٍ تجعلها غير مفهومة لأي طرفٍ ليس لديه السر لكيفية عكس هذا التحويل، حيث يطبّق المرسل عملية تشفير على رسالة نص البيانات الصرفة plaintext الأصلية، مما ينتج عنه رسالة نصٍ مشفَّر ciphertext تُرسَل عبر الشبكة كما هو موضحٌ في الشكل الآتي. يطبّق المستلم عملية فك تشفير decryption سرية، وهي معاكسة لعملية التشفير لاستعادة نص البيانات الصرفة الأصلي. لن يكون النص المشفَّر المُرسَل عبر الشبكة مفهومًا لأي متصنت إذا افترضنا أن المتنصت لا يعرف عملية فك التشفير، وسيُطلق على التحويل الذي تمثله عملية التشفير وعملية فك التشفير المقابلة لها اسم شيفرة cipher. لقد توجّه مصممو التشفير إلى المبدأ الذي ذُكِر لأول مرة في عام 1883، وهو أن عمليات التشفير وفك التشفير يجب أن يحددها مفتاح key، كما يجب عدُّ هذه العمليات عامةً وأن يكون المفتاح سريًا فقط، وبالتالي فإن النص المشفَّر الناتج عن رسالة نص بيانات صرفةٍ معين يعتمد على كلٍ من عملية التشفير والمفتاح. أحد أسباب الكامنة وراء هذا المبدأ هو أنك إذا اعتمدت على إبقاء الشيفرات سريةً، فعليك إبعاد الشيفرة وليس المفاتيح فقط عندما تعتقد أنها لم تَعُد سرية، وهذا يعني حدوث تغييراتٍ متكررة في الشيفرات، وهو أمرٌ يمثل مشكلةً نظرًا لأن الأمر يتطلب الكثير من العمل لتطوير شيفرةٍ جديدة. من أفضل الطرق لمعرفة أن الشيفرة آمنة هي استخدامها لفترة طويلة، فإذا لم يخترقها أحد من الممكن أن تكون آمنة. هناك الكثير من الأشخاص الذين سيحاولون كسر الشيفرات، وبذلك تصبح معروفةً على نطاقٍ واسع عندما ينجحون، وبالتالي هناك تكلفةٌ ومخاطرةٌ كبيرة في نشر شيفرات جديدة. أخيرًا، يوفر لنا تحديد معاملات الشيفرة بالمفاتيح مجموعةً كبيرة جدًا من الشيفرات؛ حيث نبدّل الشيفرات من خلال تبديل المفاتيح، وبالتالي نحدّ من كمية البيانات التي يمكن لمحلّل التشفير cryptanalyst أو مخترق الشيفرة استخدامها لمحاولة كسر المفتاح أو الشيفرة ونحدّ من المقدار الممكن قراءته إذا نجح. يتمثل المطلب الأساسي لخوارزمية التعمية encryption في تحويل نص البيانات/ الصرف إلى نص مشفّر، بحيث لا يتمكن سوى المستلم المقصود (صاحب مفتاح فك التشفير) من استرداد النص الأصلي. ويعني ذلك أن الرسائل المشفّرة أو المُعمَّاة لا يمكن أن يقرأها الأشخاص الذين ليس لديهم المفتاح. يجب أن ندرك أنه عندما يتلقى المهاجم المحتمل جزءًا من النص المشفر، فقد تكون لديه معلومات تحت تصرفه أكثر من مجرد النص المشفر نفسه، فربما يعلم أن النص الأصلي مكتوبٌ باللغة الإنجليزية مثلًا، مما يعني أن الحرف e يظهر في كثير من الأحيان في النص موازنةً بأي حرفٍ آخر، وبالتالي من الممكن أيضًا توقُّع تكرار العديد من الحروف الأخرى ومجموعات الحروف الشائعة. يمكن لهذه المعلومات تبسيط مهمة العثور على المفتاح كثيرًا، فقد يعرف المهاجم شيئًا عن المحتويات المحتملة للرسالة، مثل ظهور كلمة "تسجيل الدخول login" في بداية جلسة تسجيل الدخول عن بُعد، وربما يؤدي ذلك إلى تفعيل هجوم النص الأصلي المعروف known plaintext attack، والذي يكون له فرصة نجاحٍ أكبر بكثير من هجوم النص المشفر فقط ciphertext only attack؛ والأفضل من ذلك هو هجوم النص الأصلي المُختار chosen plaintext attack، والذي يمكن تفعيله من خلال تقديم بعض المعلومات إلى المرسل التي تعرف أنه يمكن أن يرسلها، حيث حدثت مثل هذه الأشياء في زمن الحرب على سبيل المثال. لذلك يمكن أن تمنع أفضلُ خوارزميات التشفير المهاجمَ من استنتاج المفتاح حتى عند معرفته بكلٍ من النص الأصلي والنص المشفَّر، وهذا لا يترك للمهاجم أي خيارٍ سوى تجربة جميع المفاتيح الممكنة، أي استخدام البحث الشامل exhaustive search بالقوة الغاشمة brute force. إذا احتوت المفاتيح على n بت، فهناك 2n قيمةً محتملة للمفتاح، حيث يمكن أن يكون كل بتٍ منها إما صفرًا أو واحدًا. وقد يكون المهاجم محظوظًا جدًا عندما يحاول تجربة القيمة الصحيحة على الفور، أو سيئ الحظ لتجربة كل قيمةٍ غير صحيحةٍ قبل تجربة قيمة المفتاح الصحيحة أخيرًا. بعد تجريب جميع قيم 2n الممكنة، يكون متوسط عدد التخمينات لاكتشاف القيمة الصحيحة هو 2n/2. قد يكون ذلك غير عمليٍ من الناحية الحسابية عن طريق اختيار حيز مفاتيحٍ كبير بما فيه الكفاية، وعن طريق جعل عملية التحقق من مفتاح مكلفةً بطريقةٍ معقولة. أدى استمرار سرعات الحوسبة في الزيادة إلى جعل هذا الأمر صعبًا، وهذا بدوره يجعل العمليات الحسابية غير المجدية سابقًا ممكنة. يجب على أفراد الأمن مراعاة عدم حصانة البيانات التي يجب أن تبقى مخزنةً في الأرشيف لعشرات السنين، على الرغم من أننا نركز على أمان البيانات أثناء انتقالها عبر الشبكة، أي أن البيانات تكون في بعض الأحيان معرضةً للخطر لفترةٍ قصيرةٍ فقط. هذا يؤدي إلى وجود مفتاح بحجمٍ كبير، لكن المفاتيح الأكبر تجعل التعمية وفك التعمية أبطأ. معظم الشيفرات ciphers هي شيفرات كتلية block ciphers، أي تُعرَّف على أن تأخذ بالدخل كتلة نصٍ أصلي بحجمٍ ثابت معيّن يكون في العادة 64 إلى 128 بتًا. يُعاني استخدام شيفرةٍ كتلية لتعمية كل كتلةٍ بصورةٍ مستقلة، والمعروف باسم وضع تعمية كتاب الشيفرة الإلكتروني electronic codebook أو اختصارًا ECB، من ضعفٍ يتمثل في أن قيمة كتلة النص الأصلي ستؤدي دائمًا إلى نفس كتلة النص المشفَّر، وبالتالي يمكن التعرف على قيم الكتل المُكررة في النص الأصلي على نفس النحو في النص المشفر، مما يسهل كثيرًا على محلل التشفير فكَّ الشيفرة. لمنع ذلك ستُزاد دائمًا الشيفرات الكتلية لجعل نص الكتلة المشفر يختلف وفقًا للسياق، حيث يُطلق على الطرق التي يمكن بها زيادة الشيفرة الكتلية اسم أنماط التشغيل modes of operation. ونمط التشغيل الشائع هو تسلسل الشيفرات الكتلية cipher block chaining أو اختصارًا CBC، حيث تُطبَّق عملية XOR على كل كتلة نصٍ أصلي قبل تشفيرها مع نص الكتلة المُشفرة السابقة، والنتيجة هي أن النص المشفر لكل كتلة يعتمد جزئيًا على الكتل السابقة، أي يعتمد على سياقها. لا تحتوي أول كتلة نصٍ أصلي على كتلةٍ سابقة، لذلك تُطبَّق عليها عملية XOR مع رقمٍ عشوائي يُدعى متجه التهيئة initialization vector أو اختصارًا IV، وهو مُضمّنٌ في سلسلة كتل النص المشفر، بحيث يمكن فك تعمية أول كتلة نصٍ مشفر، وهذا الأسلوب موضحٌ في الشكل الآتي. هناك نمط تشغيلٍ آخر هو نمط العدّاد counter mode، حيث تُدمج قيم العدّاد المتتالية (مثل 1، 2، 3، …) في تعمية الكتل المتتالية من النص الأصلي. الشيفرات ذات المفتاح السري Secret-Key Ciphers يتشارك كلا المشاركَين participants في الاتصال في نفس المفتاح في الشيفرات ذات المفتاح السري، أي إذا شُفِّرت رسالةٌ باستخدام مفتاحٍ معين، فإن المفتاح نفسه مطلوبٌ لفك تشفير الرسالة. تُعرَف شيفرات المفاتيح السرية أيضًا باسم شيفرات المفاتيح المتناظرة symmetric-key ciphers، حيث تجري مشاركة هذا المفتاح السري مع كلا المشاركين، وسنلقي نظرةً على شيفرات المفاتيح العامة public-key ciphers البديلة قريبًا. تُعرف شيفرات المفاتيح العامة أيضًا باسم الشيفرات ذات المفاتيح غير المتماثلة asymmetric-key ciphers، حيث يستخدم المشتركان مفاتيحًا مختلفة، وسنستخدم مصطلح "مشارك participant" للإشارة إلى الأطراف المشاركة في اتصالٍ آمن نظرًا لأنه المصطلح الذي استخدمناه في جميع أنحاء هذه السلسلة لتحديد نقطتي نهاية القناة، ويُطلق عليهم عادةً في عالم الأمن المسؤولون principals. أصدر المعهد الوطني الأمريكي للمعايير والتقنية U.S. National Institute of Standards and Technology أو اختصارًا NIST معاييرًا لسلسلةٍ من الشيفرات ذات المفاتيح السرية، وكان معيار تشفير البيانات Data Encryption Standard أو اختصارًا DES هو المعيار الأول، وقد صمد أمام اختبار الزمن، حيث لم يُكتشَف أي هجوم تشفيرٍ تحليلي cryptanalytic attack أفضل من البحث بالقوة الغاشمة brute force search الذي أصبح أسرع مما هو عليه. لقد أصبحت مفاتيح DES المؤلفة من 56 بتٍ مستقل الآن صغيرة جدًا نظرًا لسرعات المعالج الحالية، حيث تحتوي مفاتيح DES على 56 بتًا مستقلًا، على الرغم من أنها تحتوي على 64 بت إجماليًا، حيث أن الجزء الأخير من كل بايت هو بت تماثل أو تكافؤ parity bit. يجب عليك البحث وسطيًا عن نصف حيز 256 مفتاحًا محتملًا للعثور على المفتاح الصحيح، مما يعطي 255 = 3.6 × 1010 مفتاحًا. قد يبدو هذا كثيرًا، لكن مثل هذا البحث قابل للتطبيق على التوازي بدرجةٍ كبيرة، لذلك من الممكن أن تضع أكبر عددٍ ممكنٍ من الحواسيب في هذه المهمة، حيث أصبح الحصول على آلاف الحواسيب هذه الأيام أمرًا سهلًا، إذ من الممكن أن يؤجرك أمازون حواسيبًا مقابل بضعة سنتات في الساعة. أصبحت استعادة مفتاح DES بعد بضع ساعاتٍ أمرًا ممكنًا بحلول أواخر التسعينات، وبالتالي حدّث معهد NIST معيار DES في عام 1999 للإشارة إلى أنه يجب استخدام هذا المعيار مع الأنظمة القديمة فقط. وقد وحّد معهد NIST أيضًا معيار تشفير DES الثلاثي Triple DES أو اختصارًا 3DES، الذي يعزّز مقاومة تحليل التشفير لمعيار DES مع زيادة حجم المفتاح. يحتوي مفتاح 3DES على (168 = 3 × 56) بتًا مستقلًا، ويستخدم ثلاثة مفاتيح DES هي DES-key1 وDES-key2 وDES-key3، حيث يُطبَّق تشفير 3DES على الكتلة عن طريق إجراء تشفير DES أولًا على الكتلة باستخدام المفتاح DES-key1، ثم فك تشفير النتيجة باستخدام المفتاح DES-key2، وأخيرًا إجراء تشفير DES لتلك النتيجة باستخدام المفتاح DES-key3. تتضمن عمليةُ فك التشفير إجراءَ فك تشفير باستخدام المفتاح DES-key3، ثم إجراء تشفير باستخدام المفتاح DES-key2، ثم فك تشفيرٍ باستخدام المفتاح DES-key1. يعود السبب وراء استخدام تشفير 3DES لفك تشفير DES مع مفتاح DES إلى التعامل مع أنظمة DES القديمة؛ فإذا استخدم نظام DES القديم مفتاحًا واحدًا، فيمكن لنظام 3DES أداء نفس عملية التشفير باستخدام هذا المفتاح لكلٍ من المفاتيح DES-key1 وDES-key2 وDES-key3، حيث نشفّر ثم نفك التشفير بنفس المفتاح في الخطوتين الأوليتين لإنتاج النص الأصلي، والذي نشفّره بعد ذلك مرةً أخرى. يحل معيار 3DES مشكلة طول مفتاح معيار DES، إلا أنه يرث منه بعض أوجه القصور الأخرى. تطبيقات برمجيات معيار DES / 3DES بطيئةٌ لأن شركة IBM صمّمتها في الأصل لتطبيقها على العتاد. يستخدم معيار DES / 3DES حجم كتلة قدره 64 بتًا، حيث أن حجم الكتلة الأكبر هو أكثر كفاءةً وأكثر أمانًا. يُستبدَل الآن معيار 3DES بمعيار التشفير المتقدم Advanced Encryption Standard أو اختصارًا AES، الصادر عن معهد NIST، وقد سُمِّيت شيفرة AES الأساسية مع بعض التعديلات الطفيفة في الأصل باسم Rijndael، وهي تُنطق تقريبًا مثل راين دال، تيمنًا بأسماء مخترعَيها دايمن Daemen وريجمين Rijmen. يدعم معيار AES أطوال المفاتيح 128 أو 192 أو 256 بت، ويبلغ طول الكتلة 128 بتًا، كما أنه يسمح بالتطبيق السريع في كلٍ من البرمجيات والعتاد ولا يتطلب ذاكرةً كبيرة، مما يجعله مناسبًا للأجهزة المحمولة الصغيرة. يمتلك معيار AES بعض خصائص الأمان المثبتة رياضيًا، ولم يتعرض لأي هجماتٍ ناجحة كبيرة حتى وقت كتابة السلسلة بنسختها الأصلية. الشيفرات ذات المفتاح العام Public-Key Ciphers بديل شيفرات المفاتيح السرية هو شيفرات المفتاح العام، حيث يستخدم تشفير المفتاح العام مفتاحَين مرتبطَين ببعضهما بدلًا من مفتاحٍ واحد مشترك بين مشاركَين، بحيث يكون أحد المفاتيح للتشفير والآخر لفك التشفير، ولكن مشاركًا واحدًا فقط هو الذي يملك هذين المفتاحَين. يحتفظ المالك بسريةٍ بمفتاح فك التشفير، بحيث يمكن للمالك فقط فك تشفير الرسائل، ويُسمى هذا المفتاح مفتاحًا خاصًا private key. يجعل المالك مفتاحَ التشفير عامًا بحيث يمكن لأي شخصٍ تشفير رسائل المالك، ويُسمى هذا المفتاح مفتاحًا عامًا public key. يجب ألا يكون ممكنًا استنتاج المفتاح الخاص من المفتاح العام، وبالتالي يمكن لأي مشاركٍ الحصول على المفتاح العام وإرسال رسالةٍ مشفرة إلى مالك المفاتيح، والمالك وحده لديه المفتاح الخاص الضروري لفك التشفير. هذا السيناريو مبينٌ في الشكل التالي. نؤكد أن مفتاح التشفير العام لا فائدة منه لفك تشفير رسالة، فلا يمكنك حتى فك تشفير رسالة شفّرتها بنفسك إلا إذا كان لديك مفتاح فك التشفير الخاص. إذا فكرنا في المفاتيح على أنها تحدد قناة اتصالٍ بين المشاركين، فإن الفرق الآخر بين شيفرات المفتاح العام وشيفرات المفتاح السري هو مخطط هذه القنوات. يوفر مفتاح شيفرات المفتاح السري قناةً ذات اتجاهين بين مشاركَين، حيث يحمل كل مشاركٍ نفس المفتاح المتماثل symmetric، والذي يمكن لأي شخص استخدامه من أجل تشفير أو فك تشفير الرسائل في أيٍ من الاتجاهين. يوفر زوج المفاتيح العام / الخاص قناةً ذات اتجاهٍ واحد وهي من نوع متعدد إلى واحد many-to-one أي من كل شخصٍ لديه المفتاح العام إلى مالك المفتاح الخاص، كما هو موضحٌ في الشكل السابق. من الخصائص الإضافية المهمة لشيفرات المفتاح العام هو أنه يمكن استخدام مفتاح فك التشفير الخاص مع خوارزمية التشفير، وذلك لتشفير الرسائل، بحيث يمكن فك تشفيرها فقط باستخدام مفتاح التشفير العام. لن تكون هذه الخاصية مفيدةً للخصوصية confidentiality، حيث يمكن لأي شخصٍ لديه المفتاح العام فك تشفير مثل هذه الرسالة، وسيحتاج كل مشاركٍ إلى زوجٍ من المفاتيح الخاصة به من أجل الخصوصية ثنائية الاتجاه بين المشاركين، ويشفّر كل مشاركٍ الرسائل باستخدام المفتاح العام للمشارك الآخر. لكن هذه الخاصية تُعد مفيدةً للاستيثاق authentication لأنها تخبر مستقبِل هذه الرسالة أنه يمكن إنشاؤها بواسطة مالك المفاتيح فقط مع مراعاة بعض الافتراضات التي سنتطرق إليها لاحقًا. يوضح الشكل الآتي ذلك، حيث يجب أن يكون واضحًا من الشكل أن أي شخصٍ لديه مفتاحٌ عام يمكنه فك تشفير الرسالة المشفَّرة، ويمكن استنتاج أن المفتاح الخاص يجب استخدامه لإجراء التشفير على فرض أن نتيجة فك التشفير تطابق النتيجة المتوقعة، ولكن كيفية استخدام هذه العملية بالضبط لتوفير الاستيثاق هي موضوع قسمٍ لاحق. تُستخدم شيفرات المفتاح العام بصورةٍ أساسية للاستيثاق وتوزيع المفاتيح السرية (المتماثلة) سريًا، وتُترَك بقية الخصوصية لشيفرات المفاتيح السرية. نشر ديفي Diffie وهيلمان Hellman قديمًا مفهوم شيفرات المفتاح العام لأول مرة في عام 1976، لكن ظهرت في وقتٍ لاحق وثائقٌ تثبت اكتشاف مجموعة أمن الاتصالات والإلكترونيات البريطانية شيفرات مفاتيحٍ عامة بحلول عام 1970، وتدّعي وكالة الأمن القومي الأمريكية NSA أنها اكتشفتها في منتصف الستينات. أكثر شيفرة مفتاحٍ عام شهرةً هي RSA، والتي سُميت تيمنًا بمخترعِيها ريفست Rivest وشامير Shamir وأدليمان Adleman. تعتمد RSA على التكلفة الحسابية العالية لتحليل الأعداد الكبيرة، فمشكلة إيجاد طريقةٍ فعالة لحساب الأرقام هي المشكلة التي عمل عليها علماء الرياضيات دون جدوى منذ فترةٍ طويلةٍ قبل ظهور خوارزمية RSA في عام 1978، وقد عزّزت مقاومةُ خوارزمية RSA لتحليل التشفير الثقةَ في أمنها. تحتاج خوارزمية RSA إلى مفاتيح كبيرة نسبيًا (على الأقل 1024 بت) لتكون آمنة، وهذا أكبر من مفاتيح شيفرات المفتاح السري، لأن كسر مفتاح RSA الخاص عن طريق حساب العدد الكبير الذي يعتمد عليه زوج المفاتيح أسرع من البحث الشامل في حيز المفاتيح. تعتمد شيفرةُ المفتاح العام الأخرى المُسماة باسم الجمل ElGamal على مشكلةٍ رياضية هي مشكلة اللوغاريتم المتقطع discrete logarithm problem، والتي لم يُعثَر على حلٍ فعّال لها، وتتطلب مفاتيحًا حجمها لا يقل عن 1024 بتًا. ينشأ تباينٌ في مشكلة اللوغاريتم المتقطع عندما يكون الدخل منحنىً بيضاويًا، ويُعتقد أنه أصعب في الحساب؛ حيث يُشار إلى مخططات التشفير القائمة على هذه المشكلة باسم تشفير المنحنى البيضاوي elliptic curve cryptography. لسوء الحظ، شيفرات المفاتيح العامة أبطأ من شيفرات المفاتيح السرية، وبالتالي يستخدم التشفير شيفرات المفاتيح السرية في الغالبية العظمى، بينما تُحجَز شيفرات المفتاح العام للاستخدام في الاستيثاق وإنشاء مفتاح جلسة. المستوثقات Authenticators لا يوفر التشفير لوحده سلامة البيانات integrity، حيث يمكن أن يؤدي التعديل العشوائي لرسالة نصٍ مشفر إلى تحويلها إلى شيء يُفك تشفيره إلى نصٍ صالحٍ ظاهريًا، وبالتالي لن يكتشف المستقبل التلاعب الحاصل في الرسالة؛ كما لا يوفر التشفير وحده الاستيثاق authentication، فالقول أن رسالةً ما جاءت من مشاركٍ معين أمرٌ غير مجدٍ إذا عُدِّلت محتويات الرسالة بعد أن ينشئها ذلك المشارك، أي لا يمكن فصل سلامة البيانات عن الاستيثاق. المستوثق authenticator هو قيمةٌ مُضمَّنة في رسالةٍ مرسلة يمكن استخدامها للتحقق في نفس الوقت من استيثاق وسلامة بيانات الرسالة. سنرى كيفية استخدام المستوثقات في البروتوكولات، لكن سنركز على الخوارزميات التي تنتج المستوثقات. لابد من أن تنذكر أن المجموع الاختباري checksum وفحص التكرار الدوري cyclic redundancy check أو اختصارًا CRC هي أجزاءٌ من المعلومات تضاف إلى الرسالة حتى يكتشف المستقبل متى عدَّلت أخطاءُ البت الرسالةَ عن غير قصد. ينطبق مفهومٌ مماثل على المستوثقات مع تحدٍ إضافي متمثلٍ في أنه من المحتمل أن يفسد شخصٌ الرسالة عن عمدٍ مع عدم رغبته بأن يُكتشَف. ويتضمن المستوثق بعض الأدلة لدعم الاستيثاق على أن يعرف كل مَن أنشأ المستوثق سرًا معروفًا فقط لدى المرسل المزعوم للرسالة؛ حيث يمكن أن يكون السر مفتاحًا على سبيل المثال، كما قد يكون الدليل قيمةٌ مشفّرةٌ باستخدام هذا المفتاح، فهناك اعتماديةٌ متبادلة بين شكل المعلومات الزائدة وشكل إثبات المعرفة السرية. سنفترض أن الرسالة الأصلية لا يجب أن تكون خصوصية، وأن الرسالة المُرسَلة ستتألف من نص الرسالة الأصلي، بالإضافة إلى المستوثق. سنشرح لاحقًا الحالة التي تكون الخصوصية مطلوبةً فيها. يجمع نوعٌ من المستوثقات بين التشفير ودالة القيمة المعمَّاة المُشفّرة cryptographic hash function، حيث تُعالَج خوارزميات القيم المشفَّرة على أنها معرفةٌ عامة كما هو الحال مع خوارزميات التشفير، وتنتج دالة القيم المُعمَّاة المشفَّرة المعروفة باسم المجموع الاختباري المُشفَّر cryptographic checksum معلوماتٍ زائدة حول رسالةٍ لفضح أي تلاعب. لقد صُمِّم المجموع الاختباري المُشفَّر لكشف الفساد المتعمَّد للرسائل من قِبل الخصم، مثل كشف المجموع الاختباري أو آلية CRC عن أخطاء بتاتٍ ناتجة عن روابط مشوَّشة، وتسمى القيمة الناتجة بقيمة الرسالة المُعمَّاة المختصرة message digest، كما تُلحَق بالرسالة مثل المجموع الاختباري العادي. يكون لجميع قيم الرسائل المعمَّاة المختصرة التي تنتجها قيمةٌ معمَّاة hash معينة نفس عدد البتات، وذلك بغض النظر عن طول الرسالة الأصلية، كما يكون حيز رسائل الدخل المحتملة أكبر من حيز قيم الرسائل المعمَّاة المختصرة المحتملة، لذلك ستكون هناك رسائل دخلٍ مختلفة تنتج نفس قيمة الرسالة المعمَّاة المختصرة، مما يؤدي إلى حدوث تصادماتٍ في جدول القيم المُعمَّاة. يمكن إنشاء المستوثق من خلال تشفير قيمة الرسالة المعمَّاة المختصرة. يحسب المستقبل قيمةً مُعمَّاةً مختصرة لجزء النص الأصلي من الرسالة ويوازنه مع القيمة المعمَّاة المختصرة للرسالة التي فُك تشفيرها، فإذا كانتا متساويتين، فسيستنتج المستقبل أن الرسالة أتت فعلًا من مرسلها المزعوم، لأنها شُفِّرت بالمفتاح الصحيح ولم يعبث أحدٌ بها. لا يمكن لأي خصمٍ أن يفلت بإرسال رسالةٍ زائفة مع قيمةٍ معمَّاة مختصرة زائفة مطابقة، وذلك لأنه لن يملك المفتاح لتشفير القيمة المعمَّاة المختصرة الزائفة بصورةٍ صحيحة؛ لكن يمكن للخصم الحصول على الرسالة الأصلية ذات النص الأصلي وقيمتها المعمَّاة المختصرة المشفَّرة عن طريق التنصت. يمكن للخصم بعد ذلك نظرًا لأن دالة القيم المُعمَّاة هي معرفةٌ عامة، حساب قيمة الرسالة المعمَّاة المختصرة الأصلية وإنشاء رسائل بديلة باحثًا عن رسالةٍ لها نفس القيمة المُعمَّاة المختصرة؛ فإذا وجدها فسيتمكّن من إرسال الرسالة الجديدة مع المستوثق القديم بصورةٍ غير قابلةٍ للكشف، لذلك يتطلب الأمن أن يكون لدالة القيم المُعمَّاة خاصيةٌ أحادية الاتجاه، أي يجب أن يكون غير ممكنٍ حسابيًا للخصم أن يجد أي رسالة نصٍ أصلية لها نفس القيمة المُعمَّاة المختصرة الأصلية. يجب توزيع مخرجات دالة القيم المعمَّاة عشوائيًا إلى حدٍ ما لكي تفي بهذا المطلب، فإذا كان طول القيم المُعمَّاة المختصرة 128 بتًا وكانت هذه القيم المُعمَّاة المختصرة موزعةٌ عشوائيًا؛ فستحتاج إلى تجربة 2127 رسالة وسطيًا قبل العثور على رسالةٍ ثانية تتطابق قيمتها المُعمَّاة المختصرة مع رسالةٍ معينة. إذا لم تُوزَّع المخرجات عشوائيًا، أي إذا كان بعضها أكثر احتمالًا من غيرها، فيمكنك العثور على رسالةٍ أخرى بالنسبة لبعض الرسائل بنفس القيمة المُعمَّاة المختصرة بسهولةٍ أكبر من ذلك، مما قد يقلل من أمن الخوارزمية؛ أما إذا حاولت بدلًا من ذلك العثور فقط على أي تصادم collision (رسالتان تنتجان نفس القيمة المُعمَّاة المختصرة)، فستحتاج إلى حساب قيم مُعمَّاة مختصرة من أجل 264 رسالةٍ فقط وسطيًا. هذه الحقيقة هي أساس "هجوم عيد الميلاد birthday attack". لقد كانت هناك العديد من خوارزميات قيم التشفير المُعمَّاة الشائعة على مر السنين، بما في ذلك قيمة الرسائل المعمَّاة المختصرة Message Digest 5 أو اختصارًا MD5، وعائلة خوارزمية القيم المعمَّاة الآمنة Secure Hash Algorithm أو اختصارًا SHA، وقد عُرفت نقاط الضعف في خوارزمية MD5 والإصدارات السابقة من خوارزمية SHA لبعض الوقت، مما دفع معهد NIST إلى التوصية باستخدام خوارزمية SHA-3 في عام 2015. يمكن أن يَستخدِم تشفير القيم المُعمَّاة المختصرة إما تشفير المفتاح السري، أو تشفير المفتاح العام لإنشاء قيمةٍ مُعمَّاةٍ مختصرة لرسالةٍ مشفرة؛ فإذا اُستخدِم تشفير المفتاح العام، فستُشفَّر القيمة المعمَّاة المختصرة باستخدام مفتاح المرسل الخاص (المفتاح الذي نعتقد أنه يُستخدم لفك التشفير)، ويمكن للمستقبل أو لأي شخصٍ آخر فك تشفير القيمة المعمَّاة المختصرة باستخدام مفتاح المرسل العام. يُطلق على القيمة المعمَّاة المختصرة المشفَّرة بخوارزمية المفتاح العام، ولكن باستخدام المفتاح الخاص اسم التوقيع الرقمي digital signature لأنه يوفّر عدم الإنكار nonrepudiation مثل التوقيع المكتوب، كما يمكن لمستقبل الرسالة ذو التوقيع الرقمي أن يثبت لأي طرفٍ ثالث أن المرسل أرسل بالفعل تلك الرسالة، إذ يمكن للطرف الثالث استخدام مفتاح المرسل العام للتحقق بنفسه. لا يحتوي تشفير مفتاح القيمة المعمَّاة المختصرة السري على هذه الخاصية لأن المشتركَين فقط يعرفان المفتاح. من ناحيةٍ أخرى، من الممكن أن يُنشِئ المستقبل المزعوم الرسالة بنفسه، نظرًا لأن كلا المشاركَين يعرفان المفتاح. يمكن استخدام أي تشفير مفتاحٍ عام للتوقيعات الرقمية، مثل معيار التوقيع الرقمي Digital Signature Standard أو اختصارًا DSS وهو صيغة توقيعٍ رقمي وحّده معهد NIST. قد تستخدم توقيعات DSS أي شيفرةٍ من شيفرات المفتاح العام الثلاث، حيث يعتمد أحد هذه التوقيعات على خوارزمية RSA؛ والآخر على تشفير الجمل؛ ويُسمى الثالث خوارزمية التوقيع الرقمي باستخدام المنحنى البيضاوي Elliptic Curve Digital Signature Algorithm. هناك نوعٌ آخر من المستوثقات المشابهة، ولكنها تستخدم دالةً تشبه القيمة المُعمَّاة، حيث تأخذ قيمةً سريةً (معروفة فقط للمرسل والمستقبل) مثل معاملٍ عوضًا عن تشفير القيمة المعمَّاة، كما هو موضحٌ في الشكل الآتي. تنتج مثلُ هذه الدالة مستوثقًا يُسمى شيفرة استيثاق الرسالة message authentication code أو اختصارًا MAC، حيث يُلحق المرسل شيفرة MAC برسالة النص الأصلي، ويعيد المستقبل حساب شيفرة MAC باستخدام النص الأصلي والقيمة السرية ويوازن شيفرة MAC المعاد حسابها مع شيفرة MAC المُستلمة. من الاختلافات الشائعة في شيفرات MAC هو تطبيقُ قيم معمَّاة مُشفّرَة مثل MD5 أو SHA-1 على سلسلة رسالة النص الأصلي والقيمة السرية، كما هو موضحٌ في الشكل السابق. وتسمى القيمة المعمَّاة المختصرة الناتجة شيفرة استيثاق الرسالة ذات القيمة المعمَّاة hashed message authentication code أو اختصارًا HMAC، لأنها في الأساس شيفرة MAC. تُلحَق شيفرة HMAC بالنص الأصلي وليس بالقيمة السرية، ويمكن للمستقبل الذي يعرف القيمة السرية فقط حساب شيفرة HMAC الصحيحة للموازنة مع شيفرة HMAC المستلمة. لو لم يتعلق الأمر بخاصية أحادية الاتجاه التي تمتلكها القيمة المعمَّاة، لكان قد تمكن الخصم من العثور على المدخلات التي أدت إلى إنشاء شيفرة HMAC وموازنتها مع رسالة النص الأصلي لتحديد القيمة السرية. لقد افترضنا حتى هذه اللحظة أن الرسالة لا تملك خصوصية، لذلك يمكن نقل الرسالة الأصلية على أنها نص بياناتٍ صرف. يكفي تشفير سلسلة الرسالة بأكملها، بما في ذلك المستوثق باستخدام شيفرة MAC أو شيفرة HMAC أو القيمة المعمَّاة المختصرة المشفَّرة، وذلك لإضافة الخصوصية إلى رسالةٍ مع مستوثق. تُطبَّق الخصوصية باستخدام شيفرات المفاتيح السرية عمليًا لأنها أسرع بكثيرٍ من شيفرات المفاتيح العامة، كما أن تضمين المستوثق في التشفير يزيد الأمن وتكلفته قليلة. يُعَد التبسيط الشائع هو تشفير الرسالة مع قيمتها المعمَّاة المختصرة (الخام)، حيث تُشفَّر القيمة المعمَّاة المختصرة مرةً واحدةً فقط، وتُعَد رسالة النص المشفر بأكملها بمثابة مستوثقٍ في هذه الحالة. قد تبدو المستوثقات أنها حلٌ لمشكلة الاستيثاق، إلا أننا سنرى لاحقًا أنها أساس الحل فقط، ولكننا سنعالج مشكلة كيفية حصول المشاركين على المفاتيح أولًا. ترجمة -وبتصرّف- للقسمين Trust and Threats وCryptographic Building Blocks من فصل Network Security من كتاب Computer Networks: A Systems Approach. اقرأ أيضًا المقال السابق: ضغط الفيديو والصوت في شبكات طرف إلى طرف الحاسوبية تأمين الشبكات تأمين الشبكات اللاسلكية مقدمة في تأمين خادوم لينكس كيفية تأمين الخواديم السحابية ضد هجمات حقن SQL النسخة الكاملة من كتاب دليل الأمان الرقمي