أمثلة عن أنظمة أمن الشبكات الحاسوبية

لقد رأينا العديد من المكونات المطلوبة لتوفير جانبٍ أو جانبين من جوانب الأمن، حيث تتضمن هذه المكونات خوارزميات التشفير وآليات مفتاح التوزيع المسبق 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 مثل الوثوقية والتحكم في التدفق والتحكم في الازدحام، وغير ذلك. يبين الشكل التالي هذا الترتيب لطبقات البروتوكول.

SecureTransportLayerInsertedBetweenApplicationAndTCPLayers.png

يُعرَف بروتوكول 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 مبهَمةً ومشفَّرةً ضمن الخادم؛ تحتوي هذه التذكرة على جميع المعلومات المطلوبة لاستئناف الجلسة، ويُستخدَم السر الرئيسي نفسه عبر المصافحة، ولكن السلوك الافتراضي هو إجراء تبادل مفتاح الجلسة عند الاستئناف.

اقتباس

ملاحظة: نلفت الانتباه إلى هذا التغيير في بروتوكول TLS لأنه يوضح التحدي المتمثل في معرفة الطبقة التي يجب أن تحل مشكلةً معينة. يبدو استئناف الجلسة كما طبّقه الإصدار السابق من بروتوكول TLS فكرةً جيدة، ولكن يجب أخذها في الحسبان في سياق حالة الاستخدام السائدة، وهي بروتوكول HTTP، فقد تغيّرت معادلة كيفية تطبيق الاستئناف بواسطة بروتوكول TLS بمجرد معالجة عبء إجراء اتصالات TCP المتعددة بواسطة بروتوكول HTTP، والدرس الأكبر من ذلك هو أننا بحاجة إلى تجنّب التفكير المحدود حول اختيار الطبقة الصحيحة لتطبيق وظيفةٍ معينة، حيث تتغير الإجابة بمرور الوقت مع تطور الشبكة، فيجب إجراء تحليلٍ شاملٍ ومتعدد الطبقات للحصول على التصميم الصحيح.

أمن 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، وبمجرد تسجيل الاسم يمكن فقط لمالك مفتاح الاسم الخاص نقل الاسم أو إبطاله أو تحديث حالة التوجيه الخاصة به.

DecentralizedIdentityManagementBuiltOnABlockchainFoundation.png

يحتوي كل اسمٍ في تطبيق Blockstack على جزءٍ من حالة التوجيه المرتبطة به، والتي تحتوي على عنوانٍ أو أكثر من عناوين URL التي تشير إلى مكان العثور على معلومات هوية المستخدم عبر الإنترنت. هذه البيانات كبيرة جدًا ومكلفة جدًا، بحيث لا يمكن تخزينها على سلسلة كتلٍ مباشرةً، لذلك يطبِّق Blockstack بدلًا من ذلك طبقةً من المخادعة، حيث تُكتَب قيمة حالة التوجيه المُعمَّاة في سجل قاعدة بيانات الهويات، وينفّذ نظراء تطبيق Blockstack شبكة نشر الشائعات gossip network لنشر واستيثاق حالة التوجيه، ويحتفظ كل نظير بنسخةٍ كاملة من حالة التوجيه.

يوضّح الشكل السابق كيفية ربط كل اسمٍ مع حالة الهوية المقابلة له، حيث يستعلم العميل أولًا عند إعطائه اسمًا عن نظير تطبيق Blockstack للمفتاح العام المقابل وحالة التوجيه (الخطوة 1)، ثم يحصل العميل بعد امتلاكه حالة التوجيه على بيانات الهوية من خلال ربطها بعنوان (أو عناوين) URL الموجود بداخله ويستوثق معلومات الهوية عن طريق التحقق من توقيعها بواسطة مفتاح الاسم العام (الخطوة 2).

اقتباس

نوصي بما يلي، لمعرفة المزيد حول تطبيق Blockstack واللامركزية في الإنترنت: Blockstack: A New Internet for Decentralized Applications، أكتوبر 2017.

ترجمة -وبتصرّف- للقسم Example Systems من فصل Network Security من كتاب Computer Networks: A Systems Approach.