IKEv1 מול IKEv2 עם מפתח משותף מראש: מה שונה באימות
שתי הגרסאות מוכיחות ידיעה של המפתח המשותף מראש בלי לשלוח אותו, אך מזינות קלטים שונים לפונקציות גיבוב שונות. השוו בין שני העקבות.
שני שערים שהוגדרו עם אותו מפתח משותף מראש משלימים לחיצת יד, ולכידת מנות אינה מראה שום סוד שחוצה את החוט. זה החלק שאנשים זוכרים. החלק המעניין הוא מה כל גרסה באמת מחשבת כדי להוכיח שהסוד ידוע, מפני ש-IKEv1 ו-IKEv2 בונים את ההוכחה הזו מקלטים שונים וחושפים מידע שונה תוך כדי. קראו את שני העקבות זה לצד זה וההבדל מפסיק להיות קוסמטי.
מה ההוכחה צריכה להשיג
Diffie-Hellman נותן לשני הצדדים ערך משותף שאת החצאים הפומביים שלו יכול לחשב גם כל מי שצופה. כשלעצמו זה לא מוכיח דבר על זהות: תוקף שמשלים החלפת מפתחות מחזיק באותו ערך משותף כמו השער שלכם. שלב האימות קיים כדי לקשור את ההחלפה הזו לסוד שרק הצדדים המיועדים מחזיקים בו, ולזהויות ולפרמטרים שעליהם הסכימו.
הקשירה הזו היא הסיבה לכך שהגיבוב מכסה יותר מהמפתח. אילו כיסה רק את הסוד, תוקף היה יכול להשמיע אותו מחדש בהחלפה אחרת עם זהויות או הצעות אחרות.
IKEv1 במצב Main: לגזור SKEYID ואז להוכיח
מצב Main מריץ שישה הודעות. הזוג הראשון מנהל משא ומתן על שיוך האבטחה, השני מחליף ערכי Diffie-Hellman פומביים ו-nonce, והשלישי נושא זהויות וגיבובי אימות תחת ההצפנה שזה עתה הוקמה. RFC 2409 מגדיר את המבנה: באימות במפתח משותף מראש, SKEYID נגזר מהסוד ומשני ה-nonce, וחומר המפתח המאוחר נגזר מ-SKEYID, מהערך המשותף של Diffie-Hellman, מה-cookies ומקבועים.
הגיבוב בהודעות החמישית והשישית מחושב על ערך Diffie-Hellman, שני ה-cookies, ההצעה והזהות של השולח, עם SKEYID כמפתח. המקבל מחשב אותו מחדש עם הסוד שהוגדר אצלו. אי-התאמה מסיימת את ההחלפה, והסוד עצמו אינו מטען בשום שלב.
מצב Aggressive דוחס את אותה עבודה לשלוש הודעות, כלומר זהויות וגיבוב האימות נוסעים לפני שקיים ערוץ מוצפן. זו חשיפה אמיתית לסוד שאפשר לנחש, והיא נפרדת מהשאלה אם הסוד נשלח. IKEv1 הוצא משימוש ב-RFC 9395, ולכן עקבה ישנה היא תרגיל אבחון ולא יעד פריסה.
IKEv2: גזירה אחרת ומטען AUTH אחר
IKEv2 אינו משתמש מחדש בלוח המפתחות של IKEv1. מפתחות ה-IKE הראשוניים מגיעים מזרע שנבנה מה-nonce ומהערך המשותף של Diffie-Hellman, ושיוכי האבטחה הבנים נגזרים ממנו. המפתח המשותף מראש אינו מזין את הזרע כלל.
האימות מופיע אז כמטען AUTH. עבור אימות במפתח משותף, RFC 7296 מגדיר צורה מרופדת של הסוד, שמתקבלת בגיבוב הסוד עם המחרוזת הקבועה Key Pad for IKEv2, ואז גיבוב נתוני ההחלפה החתומים והזהות עם המפתח המרופד הזה. המאמת יכול לבנות מחדש את אותו ערך; צופה לא יכול, בלי הסוד.
שימו לב מה השתנה. ב-IKEv1 הסוד אפוי בלוח המפתחות לפני שגיבוב האימות קיים; ב-IKEv2 לוח המפתחות בלתי תלוי בסוד וההוכחה היא מטען נפרד הקשור לאוקטטים החתומים. אותה הבטחה מושגית, מכונות אחרות, ולכן שמות פרמטרים ולכידות אינם ממופים אחד לאחד.
מה צופה באמת לומד
ערכי Diffie-Hellman פומביים, הצעות, nonce ו-cookies גלויים בשתי הגרסאות. זהויות גלויות ב-IKEv1 מצב Aggressive ומוגנות במקרים האחרים. הסוד אינו גלוי לעולם.
למשפט האחרון יש גבול שראוי לומר. סוד חלש שנבחר בידי אדם ניתן לתקוף בניחוש: התוקף מחשב מה יהיה ערך האימות עבור מועמד לסוד ומשווה. מצב Aggressive של IKEv1 הופך זאת לזול ביותר מפני שהראיה גלויה, והתקנים מזהירים באופן כללי מפני סודות בעלי אנטרופיה נמוכה. אי-שליחת הסוד אינה זהה להפיכת סוד גרוע לבטוח.
מה לעשות עם ההשוואה
השתמשו בסוד ייחודי אחד לכל זוג צדדים, ייצרו אותו ממקור אקראי, וסובבו אותו באותו נתיב אספקה שהפיץ אותו. אם הסוד נמצא בתבנית תצורה שנשלחת לכל סניף, פגיעה במקום אחד היא פגיעה בכל מקום.
העדיפו אימות מבוסס תעודות היכן שהעלות התפעולית מקובלת, מפני שהוא מסיר את בעיית ניחוש הסוד המשותף ונותן לכל צד זהות נפרדת. היכן שנשאר מפתח משותף מראש, החזיקו אותו ארוך, צמצמו את היקפו והתייחסו לגרסת IKE כהחלטת אבטחה ולא כפרט של פעילות גומלין.