تبادل مفاتيح الإنترنت

📅 آخر تحديث: ٢٧ يوليو ٢٠٢٦
✍️ نُشر في: ٢٧ يوليو ٢٠٢٦
📷 يحتوي على 2 صور
الموسوعة الحرة

في الحوسبة، يعد تبادل مفاتيح الإنترنت ( IKE ، المُصنَّف كـ IKEv1 و IKEv2 ) هو البروتوكول المستخدم لإعداد ارتباط أمان (SA) في مجموعة بروتوكولات IPsec . يعتمد IKE على بروتوكول Oakley و ISAKMP . [1] يستخدم IKE شهادات X.509 للمصادقة ‒ إما مشتركة مسبقًا أو موزعة باستخدام DNS (يفضل مع DNSSEC ) ‒ وتبادل مفاتيح Diffie–Hellman لإعداد سر جلسة مشترك يتم اشتقاق المفاتيح التشفيرية منه . [2] [3] بالإضافة إلى ذلك، يجب الحفاظ على سياسة أمان لكل نظير سيتصل يدويًا. [2]

تاريخ

قامت مجموعة عمل هندسة الإنترنت (IETF) في الأصل بتعريف IKE في نوفمبر 1998 في سلسلة من المنشورات ( طلب التعليقات ) المعروفة باسم RFC 2407 وRFC 2408 وRFC 2409:

  • حدد RFC  2407 نطاق تفسير أمان IP للإنترنت لـ ISAKMP. [4]
  • حدد RFC  2408 بروتوكول جمعية أمان الإنترنت وإدارة المفاتيح (ISAKMP). [5]
  • حدد RFC  2409 تبادل المفاتيح عبر الإنترنت (IKE). [6]

قام RFC  4306 بتحديث IKE إلى الإصدار الثاني (IKEv2) في ديسمبر 2005. [7] أوضح RFC  4718 بعض التفاصيل المفتوحة في أكتوبر 2006. [8] قام RFC  5996 بدمج هاتين الوثيقتين بالإضافة إلى التوضيحات الإضافية في IKEv2 المحدث، [9] والذي نُشر في سبتمبر 2010. قام تحديث لاحق بترقية الوثيقة من المعيار المقترح إلى معيار الإنترنت ، والذي نُشر باسم RFC  7296 في أكتوبر 2014.

حافظت المنظمة الأم لـ IETF، وهي جمعية الإنترنت (ISOC)، على حقوق الطبع والنشر لهذه المعايير بحيث تكون متاحة مجانًا لمجتمع الإنترنت.

بنيان

تتكون معظم تنفيذات IPsec من برنامج IKE daemon يعمل في مساحة المستخدم ومكدس IPsec في النواة الذي يعالج حزم IP الفعلية .

تتمتع شياطين مساحة المستخدم بسهولة الوصول إلى وحدة تخزين ضخمة تحتوي على معلومات التكوين، مثل عناوين نقطة نهاية IPsec والمفاتيح والشهادات، حسب الحاجة. من ناحية أخرى، يمكن لوحدات النواة معالجة الحزم بكفاءة وبأقل تكلفة إضافية - وهو أمر مهم لأسباب تتعلق بالأداء.

يستخدم بروتوكول IKE حزم UDP ، عادةً على المنفذ 500، ويتطلب عمومًا 4-6 حزم مع 2-3 رحلات ذهابًا وإيابًا لإنشاء ارتباط أمان ISAKMP (SA) على كلا الجانبين. ثم يتم إعطاء مادة المفتاح المتفاوض عليها إلى مكدس IPsec. على سبيل المثال، يمكن أن يكون هذا مفتاح AES ، أو معلومات تحدد نقاط نهاية IP والمنافذ التي يجب حمايتها، بالإضافة إلى نوع نفق IPsec الذي تم إنشاؤه. يقوم مكدس IPsec بدوره باعتراض حزم IP ذات الصلة إذا لزم الأمر وأينما كان ذلك مناسبًا ويقوم بالتشفير/فك التشفير حسب الحاجة. تختلف التنفيذات في كيفية اعتراض الحزم - على سبيل المثال، يستخدم البعض أجهزة افتراضية، بينما يأخذ البعض الآخر شريحة من جدار الحماية، إلخ.

يتكون IKEv1 من مرحلتين: المرحلة 1 والمرحلة 2. [10]

مراحل IKEv1

الغرض من المرحلة الأولى من IKE هو إنشاء قناة اتصال آمنة وموثقة باستخدام خوارزمية تبادل المفاتيح Diffie–Hellman لتوليد مفتاح سري مشترك لتشفير المزيد من اتصالات IKE. تؤدي هذه المفاوضات إلى ارتباط أمان ISAKMP ثنائي الاتجاه واحد. [11] يمكن إجراء المصادقة باستخدام إما مفتاح مشترك مسبقًا (سر مشترك) أو التوقيعات أو تشفير المفتاح العام. [12] تعمل المرحلة الأولى إما في الوضع الرئيسي أو الوضع العدواني. يحمي الوضع الرئيسي هوية النظراء وتجزئة المفتاح المشترك عن طريق تشفيرهم؛ لا يفعل الوضع العدواني ذلك. [10]

خلال المرحلة الثانية من IKE، تستخدم أقران IKE القناة الآمنة التي تم إنشاؤها في المرحلة 1 للتفاوض على ارتباطات الأمان نيابة عن خدمات أخرى مثل IPsec . تسفر المفاوضات عن حد أدنى من ارتباطين أمنيين أحاديي الاتجاه (واحد وارد وواحد صادر). [13] تعمل المرحلة 2 في الوضع السريع فقط. [10]

مشاكل مع IKE

في الأصل، كان لدى IKE العديد من خيارات التكوين ولكنها كانت تفتقر إلى مرفق عام للتفاوض التلقائي على حالة افتراضية معروفة يتم تنفيذها عالميًا. وبالتالي، كان على جانبي IKE الاتفاق تمامًا على نوع ارتباط الأمان الذي يريدون إنشاؤه - خيارًا تلو الآخر - وإلا فلن يمكن إنشاء اتصال. نشأت تعقيدات أخرى من حقيقة أنه في العديد من التطبيقات كان من الصعب تفسير ناتج التصحيح، إذا كان هناك أي مرفق لإنتاج ناتج تشخيصي على الإطلاق.

كانت مواصفات IKE مفتوحة لدرجة كبيرة من التفسير، على حدود أخطاء التصميم ( يعتبر Dead Peer Detection مثالاً على ذلك [ بحاجة لمصدر ] )، مما أدى إلى عدم قدرة تطبيقات IKE المختلفة على إنشاء ارتباط أمان متفق عليه على الإطلاق للعديد من مجموعات الخيارات، بغض النظر عن كيفية تكوينها بشكل صحيح في أي من الطرفين.

تحسينات مع IKEv2

تم وصف بروتوكول IKEv2 في الملحق A من RFC 4306 في عام 2005. وتم تناول القضايا التالية:

  • طلبات أقل للتعليقات (RFCs): تم تغطية مواصفات IKE في ثلاثة طلبات للتعليقات على الأقل، وأكثر إذا أخذنا في الاعتبار عبور NAT والامتدادات الأخرى المستخدمة بشكل شائع. يجمع IKEv2 بين هذه في RFC واحد بالإضافة إلى إجراء تحسينات على دعم عبور NAT ( ترجمة عناوين الشبكة (NAT)) وعبور جدار الحماية بشكل عام.
  • دعم التنقل القياسي: يوجد ملحق قياسي لـ IKEv2 يسمى [rfc:4555 Mobility and Multihoming Protocol] (MOBIKE) (انظر أيضًا، IPsec ) يستخدم لدعم التنقل والتعدد في التنقل له و Encapsulating Security Payload (ESP). باستخدام هذا الملحق، يمكن للمستخدمين المتنقلين والمتعددين استخدام IKEv2 و IPsec .
  • عبور NAT : يؤدي تغليف IKE و ESP في بروتوكول بيانات المستخدم (منفذ UDP 4500) إلى تمكين هذه البروتوكولات من المرور عبر جهاز أو جدار حماية يقوم بأداء NAT . [14]
  • دعم بروتوكول نقل التحكم في التدفق (SCTP): يسمح IKEv2 باستخدام بروتوكول SCTP كما هو مستخدم في بروتوكول الهاتف عبر الإنترنت، وبروتوكول نقل الصوت عبر IP (VoIP).
  • تبادل الرسائل البسيط: يحتوي IKEv2 على آلية تبادل أولية مكونة من أربع رسائل حيث قدم IKE ثماني آليات تبادل أولية مختلفة تمامًا، ولكل منها مزايا وعيوب طفيفة.
  • آليات تشفير أقل: يستخدم IKEv2 آليات تشفير لحماية حزمه تشبه إلى حد كبير ما يستخدمه IPsec ESP لحماية حزم IPsec. وقد أدى هذا إلى تنفيذات وشهادات أبسط للمعايير المشتركة و FIPS 140-2 ( معيار معالجة المعلومات الفيدرالي (FIPS))، والذي يتطلب التحقق من صحة كل تنفيذ تشفيري على حدة.
  • الموثوقية وإدارة الحالة: يستخدم IKEv2 أرقام التسلسل والإقرارات لتوفير الموثوقية ويفرض بعض لوجستيات معالجة الأخطاء وإدارة الحالة المشتركة. يمكن أن ينتهي الأمر بـ IKE في حالة ميتة بسبب عدم وجود مثل هذه التدابير الموثوقة، حيث كان كل طرف يتوقع من الطرف الآخر أن يبدأ إجراءً - وهو ما لم يحدث أبدًا. تم تطوير حلول بديلة (مثل Dead-Peer-Detection ) ولكن لم يتم توحيدها. وهذا يعني أن التنفيذات المختلفة للحلول البديلة لم تكن متوافقة دائمًا.
  • مقاومة هجمات رفض الخدمة (DoS): لا يقوم IKEv2 بإجراء الكثير من المعالجة حتى يحدد ما إذا كان مقدم الطلب موجودًا بالفعل. وقد عالج هذا بعض مشكلات رفض الخدمة التي عانى منها IKE والتي كانت تؤدي الكثير من المعالجة التشفيرية المكلفة من مواقع مزيفة .
بافتراض أن لدى HostA فهرس معلمات الأمان (SPI) Aو لدى HostB فهرس معلمات الأمان ( SPI ) B، فإن السيناريو سيبدو كما يلي:
هوستا ------------------------------------------------- - المضيف ب
     |HDR(A,0),sai1,kei,Ni --------------------------> |
     | <----------------------------HDR(A,0)،N(ملف تعريف الارتباط)|
     |HDR(A,0),N(ملف تعريف الارتباط),sai1,kei,Ni----------------> |
     | <--------------------------HDR(A,B),SAr1,ker,Nr|
إذا كان المضيف B (المستجيب) يواجه كميات كبيرة من اتصالات IKE نصف المفتوحة، فسوف يرسل رسالة رد غير مشفرة إلى IKE_SA_INITالمضيف A (المبادر) مع رسالة إعلام من النوع COOKIE، وسيتوقع من المضيف A إرسال IKE_SA_INITطلب بقيمة ملف تعريف الارتباط هذه في حمولة إعلام إلى المضيف B . وهذا لضمان أن المبادر قادر حقًا على التعامل مع استجابة IKE من المستجيب.

امتدادات البروتوكول

قامت مجموعة عمل IETF ipsecme بتوحيد عدد من الامتدادات، بهدف تحديث بروتوكول IKEv2 وتكييفه بشكل أفضل مع بيئات الإنتاج ذات الحجم الكبير. تتضمن هذه الامتدادات:

  • استئناف جلسة IKE : القدرة على استئناف "جلسة" IKE/IPsec الفاشلة بعد الفشل، دون الحاجة إلى المرور بعملية إعداد IKE بأكملها ( RFC 5723).
  • إعادة توجيه IKE : إعادة توجيه طلبات IKE الواردة، مما يسمح بموازنة التحميل البسيطة بين نقاط نهاية IKE المتعددة ( RFC 5685).
  • رؤية حركة مرور IPsec : وضع علامات خاصة على حزم ESP التي تم مصادقتها ولكنها غير مشفرة، بهدف تسهيل تحليل التدفق على الصناديق الوسطى (مثل أنظمة اكتشاف التطفل ) ( RFC 5840).
  • مصادقة EAP المتبادلة : دعم مصادقة EAP فقط (أي بدون شهادة) لكلا نظيري IKE؛ والهدف هو السماح باستخدام طرق المصادقة الحديثة القائمة على كلمة المرور ( RFC 5998).
  • الكشف السريع عن الأعطال : تقليل الوقت حتى يكتشف نظير IKE أن نظيره الآخر قد تعطل ( RFC 6290).
  • تمديدات التوفر العالي : تحسين مزامنة بروتوكول IKE/IPsec على مستوى بين مجموعة من نقاط نهاية IPsec ونظير، لتقليل احتمالية انقطاع الاتصالات بعد حدث الفشل ( RFC 6311).

التنفيذات

يتم دعم IKE كجزء من تنفيذ IPsec في أنظمة التشغيل Windows 2000 و Windows XP و Windows Server 2003 و Windows Vista و Windows Server 2008. [15] تم تطوير تنفيذ ISAKMP/IKE بشكل مشترك بواسطة Cisco وMicrosoft. [ 16]

يدعم كل من Microsoft Windows 7 و Windows Server 2008 R2 بشكل جزئي IKEv2 ( RFC 7296) بالإضافة إلى MOBIKE ( RFC 4555) من خلال ميزة VPN Reconnect (المعروفة أيضًا باسم Agile VPN ).

توجد عدة تطبيقات مفتوحة المصدر لـ IPsec مع إمكانيات IKE المرتبطة بها. على Linux ، توفر تطبيقات Libreswan و Openswan و strongSwan برنامج IKE daemon يمكنه تكوين (أي إنشاء SAs) لمكدسات IPsec المستندة إلى نواة KLIPS أو XFRM/NETKEY. XFRM/NETKEY هو تطبيق IPsec الأصلي لنظام Linux المتوفر اعتبارًا من الإصدار 2.6.

تطبق توزيعات Berkeley Software أيضًا IPsec وIKE daemon عبر إطار عمل التشفير OpenBSD (OCF)، مما يجعل دعم مسرعات التشفير أسهل كثيرًا. تم نقل OCF مؤخرًا إلى Linux.

لقد قام عدد من بائعي معدات الشبكة بإنشاء شياطين IKE الخاصة بهم (وتنفيذات IPsec)، أو ترخيص مجموعة من بعضهم البعض.

هناك عدد من تطبيقات IKEv2 وبعض الشركات التي تتعامل في مجال شهادة IPsec واختبار التشغيل البيني بدأت في عقد ورش عمل للاختبار بالإضافة إلى متطلبات الشهادة المحدثة للتعامل مع اختبار IKEv2.

تتوفر الإصدارات المفتوحة المصدر التالية لـ IKEv2:

نقاط الضعف

تشير العروض التقديمية المسربة لوكالة الأمن القومي والتي نشرتها دير شبيجل في عام 2014 إلى أن IKE يتم استغلالها بطريقة غير معروفة لفك تشفير حركة مرور IPsec، كما هو الحال مع ISAKMP. [19] يذكر الباحثون الذين اكتشفوا هجوم Logjam أن كسر مجموعة Diffie–Hellman ذات 1024 بت من شأنه أن يكسر 66٪ من خوادم VPN، و18٪ من أفضل مليون نطاق HTTPS، و26٪ من خوادم SSH، وهو ما يدعي الباحثون أنه يتفق مع التسريبات. [20] تم دحض هذا الادعاء في عام 2015 من قبل كل من إيال رونين وأدي شامير في ورقتهما "مراجعة نقدية للسرية الأمامية غير الكاملة" [21] ومن قبل بول ووترز من Libreswan في مقال عام 2015 "66٪ من شبكات VPN [ كذا ] ليست في الواقع مكسورة". [22]

تخضع تكوينات VPN IPsec التي تسمح بالتفاوض على تكوينات متعددة لهجمات تخفيض المستوى القائمة على MITM بين التكوينات المقدمة، مع كل من IKEv1 وIKEv2. [23] ويمكن تجنب ذلك من خلال الفصل الدقيق لأنظمة العميل على نقاط وصول خدمة متعددة مع تكوينات أكثر صرامة.

كلا الإصدارين من معيار IKE عرضة لهجوم القاموس غير المتصل بالإنترنت عند استخدام كلمة مرور منخفضة الإنتروبيا. بالنسبة لـ IKEv1، ينطبق هذا على الوضع الرئيسي والوضع العدواني. [24] [25] [26]

انظر أيضا

مراجع

  1. ^ تبادل المفاتيح عبر الإنترنت (IKE)، RFC 2409، §1 الملخص
  2. ^ ab Thomas, M. (يونيو 2001)، RFC 3129: متطلبات التفاوض على المفاتيح عبر الإنترنت باستخدام Kerberized، فريق عمل هندسة الإنترنت ، ص. 1، doi : 10.17487/RFC3129
  3. ^ ريتشاردسون، م.؛ ريدلماير، دي إتش (يونيو 2001)، RFC 4322: التشفير الانتهازي باستخدام تبادل المفاتيح عبر الإنترنت (IKE)، فريق عمل هندسة الإنترنت ، ص. 5، doi :10.17487/RFC4322
  4. ^ مجال تفسير أمان بروتوكول الإنترنت الخاص بـ ISAKMP. doi : 10.17487/RFC2407 . RFC 2407.
  5. ^ جمعية أمان الإنترنت وبروتوكول إدارة المفاتيح (ISAKMP). doi : 10.17487/RFC2408 . RFC 2408.
  6. ^ د. هاركينز. تبادل المفاتيح عبر الإنترنت (IKE). doi : 10.17487/RFC2409 . RFC 2409.
  7. ^ C. Kaufman (Microsoft) (ديسمبر 2005). بروتوكول تبادل المفاتيح عبر الإنترنت (IKEv2). doi : 10.17487/RFC4306 . RFC 4306.
  8. ^ Eronen, P.; Hoffman, P. (أكتوبر 2006). توضيحات وإرشادات تنفيذ IKEv2. doi : 10.17487/RFC4718 . RFC 4718.
  9. ^ Kaufman, C.; Hoffman, P.; Nir, Y.; Eronen, P. (سبتمبر 2010). بروتوكول تبادل المفاتيح عبر الإنترنت (IKEv2). doi : 10.17487/RFC5996 . RFC 5996.
  10. ^ abc "RFC 2409 تبادل مفاتيح الإنترنت (IKE)"، فريق عمل هندسة الإنترنت (IETF)، ص. 5
  11. ^ "RFC 2409 تبادل المفاتيح عبر الإنترنت (IKE)"، فريق عمل هندسة الإنترنت (IETF)، ص. 6
  12. ^ "RFC 2409 تبادل المفاتيح عبر الإنترنت (IKE)"، فريق عمل هندسة الإنترنت (IETF)، ص. 10-16
  13. ^ "بروتوكول تبادل المفاتيح عبر الإنترنت (IKEv2) RFC 4306"، فريق عمل هندسة الإنترنت (IETF)، ص 11، 33
  14. ^ "RFC 4306: بروتوكول تبادل المفاتيح عبر الإنترنت (IKEv2)"، فريق عمل هندسة الإنترنت (IETF)، ص 38-40
  15. ^ تبادل مفاتيح الإنترنت: أمان بروتوكول الإنترنت (IPsec): Technet
  16. ^ "استخدام IPSec في Windows 2000 وXP، الجزء الأول". مؤرشف من الأصل في 12 أكتوبر 2008. تم الاسترجاع في 24 ديسمبر 2009 .
  17. ^ "OpenIKEv2". GitHub . تم الاسترجاع في 2023-06-21 .
  18. ^ "iked(8) - صفحات دليل OpenBSD". man.openbsd.org . تم الاسترجاع في 2023-06-21 .
  19. ^ Fielded Capability: End-to-end VPN SPIN9 Design Review (PDF) ، NSA عبر "Der Spiegel"، ص. 5
  20. ^ أدريان، ديفيد؛ بهارجافان، كارثيكيان؛ دوروميريك، زاكير؛ جودري، بيريك؛ جرين، ماثيو؛ هالديرمان، ج. أليكس؛ هينينجر، ناديا ؛ سبرينجال، درو؛ تومي، إيمانويل؛ فالينتا، لوك؛ فانديرسلوت، بنيامين؛ ووسترو، إيريك؛ زانيلا بيجولين، سانتياجو؛ زيمرمان، بول (أكتوبر 2015). السرية الأمامية غير الكاملة: كيف تفشل ديفي هيلمان في الممارسة (PDF) . المؤتمر الثاني والعشرون لجمعية مكائن ​​الحوسبة حول أمن الكمبيوتر والاتصالات (CCS '15). دنفر . تم الاسترجاع في 15 يونيو 2016 .
  21. ^ رونين، إيال؛ شامير، آدي (أكتوبر 2015). "مراجعة نقدية للسرية المسبقة غير الكاملة" (PDF) .
  22. ^ Wouters, Paul (أكتوبر 2015). "66% من شبكات VPN ليست معطلة في الواقع".
  23. ^ بهارجافان ، كارثيكيان. برزوسكا، كريستينا؛ فورنيه، سيدريك؛ كولويس، ماركولف. زانيلا بيجولين، سانتياغو؛ جرين ماثيو (يناير 2016). "خفض مستوى المرونة في بروتوكولات تبادل المفاتيح" (PDF) .
  24. ^ بليام، جون (2 أكتوبر 1999). "ثغرات المصادقة في IKE وXauth مع الأسرار المشتركة الضعيفة مسبقًا". جامعة جونز هوبكنز . مؤرشف من الأصل في 10 يونيو 2002. تم الاسترجاع في 5 فبراير 2020 .
  25. ^ McGrew, David (5 يوليو 2011). "شفرة عظيمة، لكن من أين حصلت على هذا المفتاح". مدونة سيسكو . مؤرشف من الأصل في 9 يوليو 2011. تم الاسترجاع في 11 فبراير 2020 .
  26. ^ Felsch, Dennis (أغسطس 2018). مخاطر إعادة استخدام المفاتيح: هجمات عملية على IPsec IKE. ISBN 9781939133045تم الاسترجاع بتاريخ 11 فبراير 2020 . {{cite book}}: |website=تم تجاهله ( مساعدة )
  • RFC 2407 رابطة أمان الإنترنت وبروتوكول إدارة المفاتيح (ISAKMP)، فريق عمل هندسة الإنترنت (IETF)
  • RFC 2409 تبادل مفاتيح الإنترنت (IKE)، فريق عمل هندسة الإنترنت (IETF)
  • RFC 7296: بروتوكول تبادل مفاتيح الإنترنت الإصدار 2 (IKEv2)، فريق عمل هندسة الإنترنت (IETF)
  • نظرة عامة على IKE (من شركة Cisco)
تم الاسترجاع من "https://en.wikipedia.org/w/index.php?title=Internet_Key_Exchange&oldid=1245727293"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate