IKEv1 در برابر IKEv2: احراز هویت با کلید از پیش اشتراکی و تفاوت‌ها
هر دو نسخه دانستن کلید از پیش اشتراکی را بدون ارسال آن اثبات می‌کنند، اما ورودی‌های متفاوتی را به هش‌های متفاوت می‌دهند. دو رد را مقایسه کنید.
دو دروازه که با همان کلید از پیش اشتراکی پیکربندی شده‌اند، دست‌دادن را کامل می‌کنند و ضبط بسته هیچ رازی را نشان نمی‌دهد که از سیم بگذرد. این همان بخشی است که مردم به یاد می‌آورند. بخش جالب این است که هر نسخه واقعاً چه چیزی را محاسبه می‌کند تا ثابت کند راز معلوم است، چون IKEv1 و IKEv2 آن اثبات را از ورودی‌های متفاوت می‌سازند و در این میان اطلاعات متفاوتی را آشکار می‌کنند. دو رد را کنار هم بخوانید تا تفاوت دیگر ظاهری نباشد.
اثبات باید چه کاری انجام دهد
دیفی-هلمن به هر دو طرف یک مقدار مشترک می‌دهد که نیمه‌های عمومی آن را هر تماشاگری هم می‌تواند محاسبه کند. این به‌تنهایی هیچ چیز درباره هویت ثابت نمی‌کند: مهاجمی که یک تبادل کلید را کامل می‌کند، همان مقدار مشترکی را دارد که دروازه شما دارد. مرحله احراز هویت وجود دارد تا آن تبادل را به رازی ببندد که تنها طرف‌های موردنظر آن را در اختیار دارند، و به هویت‌ها و پارامترهایی که بر آن توافق کرده‌اند.
همین بستگی دلیل آن است که هش بیش از کلید را پوشش می‌دهد. اگر فقط راز را پوشش می‌داد، مهاجم می‌توانست آن را در تبادلی دیگر با هویت‌ها یا پیشنهادهای متفاوت بازپخش کند.
IKEv1، حالت اصلی: مشتق‌کردن SKEYID و سپس اثبات آن
حالت اصلی شش پیام اجرا می‌کند. جفت اول درباره انجمن امنیتی مذاکره می‌کند، دوم مقادیر عمومی دیفی-هلمن و نانس‌ها را مبادله می‌کند، و سوم هویت‌ها به‌همراه هش‌های احراز هویت را زیر رمزنگاری تازه‌برقرارشده حمل می‌کند. RFC 2409 این ساختار را تعریف می‌کند: با احراز هویت کلید از پیش اشتراکی، SKEYID از راز و هر دو نانس مشتق می‌شود، و مواد کلیدی بعدی از SKEYID، مقدار مشترک دیفی-هلمن، کوکی‌ها و ثابت‌ها مشتق می‌شود.
هش در پیام‌های پنجم و ششم روی مقدار دیفی-هلمن، دو کوکی، پیشنهاد و هویت فرستنده و با کلید SKEYID محاسبه می‌شود. گیرنده آن را با راز پیکربندی‌شده خود دوباره محاسبه می‌کند. ناهمخوانی تبادل را پایان می‌دهد و در هیچ نقطه‌ای خود راز یک بار مفید نیست.
حالت تهاجمی همان کار را به سه پیام فشرده می‌کند، یعنی هویت‌ها و هش احراز هویت پیش از آنکه کانال رمزشده‌ای وجود داشته باشد سفر می‌کنند. این برای راز قابل‌حدس یک افشای واقعی است و از این پرسش جدا است که آیا راز منتقل شده یا نه. IKEv1 با RFC 9395 منسوخ شده است، پس یک رد قدیمی تمرینی تشخیصی است نه هدفی برای استقرار.
IKEv2: مشتق‌سازی متفاوت و بار AUTH متفاوت
IKEv2 برنامه کلید IKEv1 را دوباره استفاده نمی‌کند. کلیدهای اولیه IKE از بذری می‌آیند که از نانس‌ها و مقدار مشترک دیفی-هلمن ساخته شده است، و انجمن‌های امنیتی فرزند از آن مشتق می‌شوند. کلید از پیش اشتراکی اصلاً بذر را تغذیه نمی‌کند.
سپس احراز هویت به‌صورت بار AUTH ظاهر می‌شود. برای احراز هویت با کلید مشترک، RFC 7296 شکل پدشده‌ای از راز را تعیین می‌کند که با هش‌کردن راز با رشته ثابت Key Pad for IKEv2 و سپس هش‌کردن داده‌های امضاشده تبادل و هویت با آن کلید پدشده تولید می‌شود. تأییدکننده می‌تواند همان مقدار را بازسازی کند؛ ناظر بدون راز نمی‌تواند.
توجه کنید چه چیزی تغییر کرد. در IKEv1 راز پیش از آنکه هش احراز هویت وجود داشته باشد در برنامه کلید پخته می‌شود؛ در IKEv2 برنامه کلید از راز مستقل است و اثبات یک بار جداگانه است که به اکتت‌های امضاشده گره خورده است. همان تضمین مفهومی، ماشین‌آلات متفاوت، و به همین دلیل نام پارامترها و ضبط‌ها یک‌به‌یک به هم نگاشت نمی‌شوند.
ناظر واقعاً چه چیزی می‌آموزد
مقادیر عمومی دیفی-هلمن، پیشنهادها، نانس‌ها و کوکی‌ها در هر دو نسخه دیدنی هستند. هویت‌ها در حالت تهاجمی IKEv1 دیدنی و در موارد دیگر محافظت‌شده‌اند. راز هرگز دیدنی نیست.
آن جمله آخر حدی دارد که ارزش گفتن دارد. راز ضعیف و انتخاب‌شده توسط انسان را می‌توان با حدس زدن مورد حمله قرار داد: مهاجم محاسبه می‌کند مقدار احراز هویت برای یک راز نامزد چه می‌شود و مقایسه می‌کند. حالت تهاجمی IKEv1 این کار را ارزان‌ترین می‌کند چون شواهد آشکار است، و استانداردها به‌طور کلی درباره رازهای کم‌آنتروپی هشدار می‌دهند. هرگز منتقل نکردن راز با ایمن کردن یک راز بد یکی نیست.
با این مقایسه چه باید کرد
برای هر جفت طرف یک راز یکتا به کار ببرید، آن را از منبعی تصادفی تولید کنید و آن را از همان مسیر تأمینی که آن را توزیع کرد بچرخانید. اگر راز در قالبی پیکربندی ذخیره شده که به هر شعبه فرستاده می‌شود، نفوذ در یک نقطه نفوذ در همه‌جاست.
جایی که هزینه عملیاتی قابل‌قبول است احراز هویت مبتنی بر گواهی را ترجیح دهید، چون مشکل حدس زدن راز مشترک را برمی‌دارد و به هر طرف هویتی متمایز می‌دهد. جایی که کلید از پیش اشتراکی می‌ماند، آن را بلند نگه دارید، دامنه‌اش را باریک کنید و نسخه IKE را تصمیمی امنیتی بدانید نه جزئیاتی از هم‌کنش‌پذیری.