مبادله کلید اینترنت
در محاسبات، مبادله کلید اینترنت (، گاهی IKEv1 یا IKEv2، بسته به نسخه) پروتکل مورد استفاده برای راه اندازی یک انجمن امنیتی (SA) در مجموعه پروتکل IPsec است که بر اساس پروتکل اوکلی و ساخته شده‌است. IKE از گواهینامه‌های X.509 برای تأیید اعتبار استفاده می‌کند - یا از قبل به اشتراک گذاشته شده یا با استفاده از DNS (ترجیحاً با DNSSEC) توزیع شده - و یک مبادله کلید Diffie-Hellman برای تنظیم یک جلسه مشترک مخفی که از آن کلیدهای رمزنگاری گرفته می‌شوند.
کارگروه مهندسی اینترنت (IETF) در اصل IKE را در نوامبر ۱۹۹۸ در یک سری نشریات (درخواست نظر - RFC) معروف به RFC 2408 ، RFC 2407 و RFC 2409 تعریف کرد:
RFC 4306 در دسامبر 2005 پروتکل IKE را به نسخه دوم (IKEv2) به روز کرد. RFC 4718 در اکتبر ۲۰۰۶ برخی از جزئیات را روشن کرد. RFC 5996 این دو سند و توضیحات اضافی را در IKEv2 به روز شده که در سپتامبر ۲۰۱۰ منتشر شد، ترکیب کرد. به روزرسانی بعدی، این سند را از نسخه پیشنهادی استاندارد به استاندارد اینترنت ، که در اکتبر ۲۰۱۴ به عنوان RFC 7296 منتشر شده‌است، ارتقا داد.
سازمان اصلی IETF، انجمن اینترنتی (ISOC)، کپی رایت این استانداردها را بصورت رایگان در دسترس جامعه اینترنت حفظ کرده‌است.
اکثر پیاده‌سازی‌های IPsec شامل یک Daemon IKE است که در فضای کاربر و یک پشته IPsec در هسته اجرا می‌شود که بسته‌های IP واقعی را پردازش می‌کند.
مکانهای فضای کاربر در صورت لزوم دسترسی آسان به ذخیره انبوه شامل اطلاعات پیکربندی مانند آدرس‌های انتهایی IPsec، کلیدها و گواهینامه‌ها دارند. از طرف دیگر ماژول‌های هسته می‌توانند بسته‌ها را به صورت کارآمد و با حداقل سربار پردازش کنند - که به دلایل عملکرد بسیار مهم است.
پروتکل IKE از بسته‌های UDP، معمولاً در پورت ۵۰۰ استفاده می‌کند، و به‌طور کلی برای ایجاد یک SA (انجمن امنیتی) از هر دو طرف به ۴–۶ بسته با ۲–۳ دور سفر نیاز دارد. مواد اصلی مورد مذاکره سپس به پشته IPsec داده می‌شود. به عنوان مثال، این می‌تواند یک کلید AES باشد؛ اطلاعاتی که نقاط پایانی IP و پورت‌هایی را که باید محافظت شوند، و همچنین نوع تونل IPsec ساخته شده را شناسایی می کند. IPsec، به نوبه خود، بسته‌های IP مربوطه را در صورت لزوم رهگیری می‌کند و رمزگذاری / رمزگشایی را طبق نیاز انجام می‌دهد. پیاده‌سازی‌ها بستگی به نحوه عملکرد رهگیری بسته‌ها دارد. مثلاً برخی از دستگاه‌های مجازی استفاده می‌کنند، برخی دیگر برشی را از دیواره آتش می‌گیرند و غیره.
IKEv1 از دو مرحله تشکیل شده‌است: فاز ۱ و فاز 2.
هدف IKE فاز اول ایجاد کانال ارتباطی معتبر با استفاده از الگوریتم تبادل کلید Diffie-Hellman برای تولید یک کلید مخفی مشترک برای رمزگذاری ارتباطات IKE است. این مذاکره منجر به یک انجمن امنیتی دو جانبه ای ( ISAKMP (SA می‌شود. احراز هویت را می‌توان با استفاده از کلید پیش اشتراک شده(راز مشترک)، امضاها یا رمزگذاری کلید عمومی انجام داد. فاز ۱ در حالت اصلی یا حالت تهاجمی عمل می‌کند. حالت اصلی با رمزگذاری آنها، از هویت همتایان و هش کلیدهای مشترک محافظت می‌کند و حالت تهاجمی ندارد.
در فاز دوم IKE، همتایان IKE از کانال ایمن مستقر در فاز ۱ برای مذاکره انجمنهای امنیتی به نمایندگی از سایر خدمات مانند IPsec استفاده می‌کنند. مذاکرات منجر به حداقل دو انجمن امنیتی یک طرفه (یک درون مرزی و یک برون مرزی) می‌شود. فاز ۲ فقط در حالت سریع (Quick Mode) عمل می‌کند.
در اصل، IKE گزینه‌های پیکربندی بی شماری را داشت اما فاقد امکانات کلی برای مذاکره خودکار برای یک مورد پیش فرض شناخته شده‌است که به‌طور جهانی اجرا می‌شود. در نتیجه، هر دو طرف IKE مجبور بودند دقیقاً در مورد نوع انجمن امنیتی که می‌خواستند ایجاد کنند، توافق کنند - گزینه به گزینه - یا امکان ایجاد ارتباط وجود نداشت. عوارض بیشتر ناشی از این واقعیت است که در بسیاری از پیاده‌سازی‌ها، در صورت وجود هرگونه امکانات برای تولید خروجی تشخیصی (diagnostic output)،تفسیر خروجی اشکال زدایی دشوار بود.
مشخصات IKE در حد قابل توجهی از تفسیر واضح بودند؛ محدود بودن به خطاهای طراحی ( Dead-Peer-Detection مورد در مورد ) و به وجود آوردن پیاده سازی های مختلف IKE به هیچ وجه قادر به ایجاد یک انجمن امنیتی توافق شده برای بسیاری از گزینه ها نیست ، با این حال به درستی پیکربندی شده است و ممکن است در انتهای هرکدام از آنها ظاهر شود.
پروتکل IKEv2 در پیوست RFC 4306 در سال ۲۰۰۵ شرح داده شده و به موضوعات زیر پرداخته شد:
کارگروه IETF ipsecme تعدادی از برنامه‌های استاندارد را با هدف مدرن سازی پروتکل IKEv2 و تطبیق بهتر آن با محیط‌های با حجم بالا، بطور استاندارد تنظیم کرده‌است. این پسوندها شامل موارد زیر است:
IKE به عنوان بخشی از پیاده‌سازی IPsec در Windows 2000، Windows XP، Windows Server 2003، Windows Vista و Windows Server 2008 پشتیبانی می‌شود. اجرای ISAKMP / IKE به‌طور مشترک توسط سیسکو و مایکروسافت تهیه شده‌است.
چندین پیاده‌سازی منبع باز از IPsec با قابلیت IKE همراه وجود دارد. در لینوکس، پیاده‌سازی Libreswan , Openswan و strongSwan یک Daemon IKE را ارائه می‌دهد که می‌تواند پیکربندی‌های IPSec را با هسته KLIPS یا XFRM / NETKEY پیکربندی کند. XFRM / NETKEY اجرای IPsec بومی لینوکس است که از نسخه ۲٫۶ موجود است.
توزیع نرم‌افزار Berkeley همچنین دارای پیاده‌سازی IPsec و Daemon IKE و از همه مهمتر یک چارچوب رمزنگاری (OpenBSD Cryptographic Framework , OCF) است که پشتیبانی از شتاب‌دهنده‌های رمزنگاری را بسیار ساده‌تر می‌کند. OCF اخیراً به لینوکس منتقل شده‌است.
تعداد قابل توجهی از فروشندگان تجهیزات شبکه، Daemons IKE (و پیاده‌سازی IPsec) خود را ایجاد کرده‌اند، یا یک پشته را از یکدیگر مجوز داده‌اند.
تعدادی از پیاده‌سازی‌های IKEv2 وجود دارد و برخی از شرکت‌هایی که در صدور گواهینامه IPsec و آزمایش قابلیت کارکردن مشغول به کار هستند، شروع به برگزاری کارگاه‌های آزمایش برای آزمایش و همچنین الزامات اخذ گواهینامه به روز شده برای مقابله با آزمایش IKEv2 می‌کنند. آزمایشگاه‌های ICSA آخرین مارس کارگاه قابلیت همکاری IKEv2 خود را در اورلاندو، فلوریدا در مارس ۲۰۰۷ با ۱۳ فروشنده از سراسر جهان برگزار کرد.
پیاده‌سازی‌های منبع باز زیر IKEv2 در حال حاضر در دسترس هستند:
ارائه NSA منتشر شده توسط "Der Spiegel" نشان می‌دهد که IKE به شیوه ای ناشناخته برای رمزگشایی ترافیک IPSec، مانند ISAKMP مورد سوء استفاده قرار می‌گیرد. محققانی که حمله Logjam را کشف کرده‌اند اظهار داشتند که شکستن یک گروه ۱۰۲۴ بیتی Diffie-Hellman باعث شکستن ۶۶٪ سرورهای VPN، ۱۸٪ از میلیون‌ها دامنه HTTPS برتر و ۲۶٪ از سرورهای SSH می‌شود که محققان ادعا می‌کنند مطابق با نشت. این ادعا توسط Eyal Ronen و Adi Shamir در مقاله خود «نقد انتقادی از رازهای بی نقص به جلو» و توسط Paul Wouters از لیبرسوان در مقاله ای «66% VPN در حقیقت شکسته نیستند» رد شد
تنظیمات IPSec VPN که امکان مذاکره در مورد پیکربندی‌های متعدد را فراهم می‌کند، در معرض حملات تخریب مبتنی بر MITM بین تنظیمات ارائه شده، با IKEv1 و IKEv2 قرار می‌گیرند. با تفکیک دقیق سیستم‌های مشتری در نقاط دسترسی به خدمات متعدد با تنظیمات دقیق تر می‌توان از این امر جلوگیری کرد.
هر دو نسخه از استاندارد IKE در هنگام استفاده از رمز ورود آنتروپی پایین مستعد حمله دیکشنری آفلاین هستند. برای IKEv1 این مسئله در مورد حالت اصلی و حالت تهاجمی صادق است.