הגנה במערכות מתוכנתות תרגול 13 – IKE הערה: שקפים אלה אינם מהווים תחליף לחומר התרגולים המפורסם באתר הקורס, ומשמשים כעזר הוראה בלבד.

הגנה במערכות מתוכנתות - תרגול 132 (c) אריק פרידמן 2007 IKE – Internet Key Exchange פרוטוקול להסכמה על מפתחות. תפקיד עיקרי: לבנות SA משותף עבור IPsec. ממומש כאפליקציה העובדת מעל UDP בפורט 500. נועד לספק:  סודיות  אימות  Identity Protection  PFS – Perfect Forward Secrecy חשיפת מפתח ארוך טווח לא חושפת מפתחות קצרי טווח

הגנה במערכות מתוכנתות - תרגול 133 (c) אריק פרידמן 2007 סקירה - מה נראה IKE עמיד בפני:  התחזות  Denial of Service, במקרים מסויימים  התקפת שידור חוזר  Man in the middle

הגנה במערכות מתוכנתות - תרגול 134 (c) אריק פרידמן 2007 סקירה - מה נראה מבנה IKE  פאזה I: יצירת ערוץ מאובטח המגן על הפאזה השנייה. Main Mode (6 הודעות מועברות) Aggressive Mode (3 הודעות מועברות)  לא מספקת הגנה כנגד DoS ו-Identity Protection. אימות באמצעות סוד משותף (pre-shared secret) אימות באמצעות חתימות  פאזה II: Quick Mode – בניית SA עבור IPsec.  שני צדדים: יוזם (initiator) ומגיב (responder). שתי דרכי הפעלה מספר דרכי אימות

הגנה במערכות מתוכנתות - תרגול 135 (c) אריק פרידמן 2007 Main Mode שלושה שלבים: 1. הסכמה על SA משותף. ISAKMP SA (Internet Security Association and Key Management Protocol) 2. החלפת מפתחות Diffie-Hellman ישמשו לגזירת המפתחות לפאזה השניה 3. אימות הצדדים ושני השלבים הראשונים בכל שלב נשלחות שתי הודעות  סה"כ 6 הודעות ב-Main Mode.

הגנה במערכות מתוכנתות - תרגול 136 (c) אריק פרידמן 2007 Main Mode – שלב ראשון המטרה: הסכמה על SA משותף ה-cookies – מחרוזות אקראיות  מוחלפות בכל הפעלה של הפרוטוקול.  משמשות כ-session identifiers אין session ב-UDP: ה-cookies ירשמו ב-header בכל הודעה החל מהשניה  הגנה מפני DoS (רק ב-Main Mode) – הרחבה בהמשך. initiator responder HDR, SA i   HDR,SA r מכיל cookie של היוזם, נסמנו ב-CKY i רשימת אלגוריתמי הצפנה ואימות כולל את CKY i, ו-cookie חדש של המגיב, נסמנו CKY r בחירה של המגיב ל- SA מתוך SA i.

הגנה במערכות מתוכנתות - תרגול 137 (c) אריק פרידמן 2007 Main Mode – שלב שני המטרה: החלפת מפתחות DH N i, N r - nonces – מחרוזות אקראיות  תפקידם להוסיף טריות להפעלה של הפרוטוקול.  בכל הפעלה של הפרוטוקול כל צד צריך לבחור nonce חדש. initiator responder HDR, g x i,N i   HDR,g x r, N r מכיל CKY i, CKY r

הגנה במערכות מתוכנתות - תרגול 138 (c) אריק פרידמן 2007 Main Mode – שלב שלישי המטרה: אימות הצדדים ושני השלבים הראשונים הסרטיפיקטים הם אופציונליים  ישלחו רק באימות באמצעות חתימות. החלק שאחרי * מועבר באופן מוצפן  ההצפנה נעשית ע"י SA עליו הוסכם בשלבים הראשונים - מפתח SKEYID e. רק בשלב זה הזהויות נחשפות (בחלק המוצפן) initiator responder HDR*, ID i, [Cert i ], AUTH i   HDR*, ID r, [Cert r ], AUTH r אימות היוזם והמגיב

הגנה במערכות מתוכנתות - תרגול 139 (c) אריק פרידמן 2007 גזירת המפתחות ע"י פונקציה פסאודו אקראית  PRF – pseudo random function  בד"כ תמומש כפונקציית תמצות עם מפתח (  חד-כיוונית)  מסכימים על הפונקציה בשלב החלפת ה-SA קביעת מפתח SKEYID  אימות עם סוד משותף pss (pre-shared secret): SKEYID = PRF pss (N i | N r )  אימות באמצעות חתימות: SKEYID = PRF N i | N r (g x i x r )  מחרוזת סודית – לעולם לא תועבר על הרשת

הגנה במערכות מתוכנתות - תרגול 1310 (c) אריק פרידמן 2007 אימות הצדדים בעזרת המחרוזות AUTH r, AUTH i : HASH i =PRF SKEYID (g x i | g x r | CKY i | CKY r | SA i | ID i ) HASH r =PRF SKEYID (g x r | g x i | CKY r | CKY i | SA i | ID r ) שתי המחרוזות כוללות את SA i  למנוע החלפת האלגוריתמים שהוצעו בחלשים יותר AUTH r AUTH i SKEYID אימות עם סוד משותף: HASH r HASH i PRF pss (N i | N r ) אימות באמצעות חתימות: Sig r (HASH r ) Sig i (HASH i ) PRF N i | N r (g x i x r )

הגנה במערכות מתוכנתות - תרגול 1311 (c) אריק פרידמן 2007 גזירת המפתחות לפאזה השניה גוזרים שלוש מפתחות  SKEYID d – ישמש לגזירת מפתחות בפאזה השניה: SKEYID d = PRF SKEYID (g x i x r | CKY i | CKY r | 0(  SKEYID a – ישמש לאימות הפאזה השניה: SKEYID a = PRF SKEYID (SKEYID d | g x i x r | CKY i | CKY r | 1(  SKEYID e – ישמש להצפנת הפאזה השנייה והשלב השלישי ב-Main Mode SKEYID e = PRF SKEYID (SKEYID a | g x i x r | CKY i | CKY r | 2(

הגנה במערכות מתוכנתות - תרגול 1312 (c) אריק פרידמן 2007 סיכום ביניים – Main Mode IKE מספק:  סודיות – SKEYID d משמש להגנה על הפאזה השנייה.  אימות – באמצעות מחרוזות AUTH.  Identity Protection – הזהויות מועברות בצורה מוצפנת מה לגבי התקפה אקטיבית?...  PFS – יצירת מפתחות DH חדשים בכל ריצה IKE עמיד בפני:  התחזות – אימות עם pss או חתימות  Denial of Service – באמצעות cookies, נראה בהמשך  התקפת שידור חוזר – nonce חדשים בכל ריצה  Man in the middle – ע"י חתימות על תוכן ההודעות

הגנה במערכות מתוכנתות - תרגול 1313 (c) אריק פרידמן 2007 Aggressive Mode שלוש הודעות בלבד: משמעות הסימונים כמו ב-Main Mode. אין הצפנות initiator responder HDR, SA i, g x i, N i, ID i   HDR, SA r, g x r, N r, ID r,, AUTH r HDR, AUTH i 

הגנה במערכות מתוכנתות - תרגול 1314 (c) אריק פרידמן 2007 Main Mode vs. Aggressive Mode Main Mode – 6 הודעות Aggressive Mode – 3 הודעות המחיר שמשלמים:  Identity Protection  הגנה כנגד Denial of Service

הגנה במערכות מתוכנתות - תרגול 1315 (c) אריק פרידמן 2007 Identity Protection הסתרה של זהויות הצדדים המשתתפים בפרוטוקול. לכאורה מתקיים תמיד ב-Main Mode  זהויות המשתתפים מועברות בצורה מוצפנת (בשלב השלישי) בפועל מתקיים רק באימות באמצעות חתימות  זהויות היוזם והמגיב מוגנות כנגד התקפה פאסיבית  זהות המגיב מוגנת גם כנגד התקפה אקטיבית

הגנה במערכות מתוכנתות - תרגול 1316 (c) אריק פרידמן 2007 Identity Protection - אימות עם pss SKEYID = PRF pss (N i | N r ) SKEYID e SKEYID a SKEYID HASH i HASH r SKEYID d pss ID i, ID r gxixrgxixr x  y : לצורך חישוב y יש לדעת את x יחס טרנזיטיבי הושמטו תלויות שחוזרות על עצמן. מעגל של תלויות!  זיהוי היוזם נעשה ע"י כתובת ה-IP שלו: ID i = IP i

הגנה במערכות מתוכנתות - תרגול 1317 (c) אריק פרידמן 2007 Identity Protection - אימות עם חתימות SKEYID = PRF N i | N r (g x i x r ) SKEYID e SKEYID a SKEYID HASH i HASH r SKEYID d ID i, ID r gxixrgxixr x  y : לצורך חישוב y יש לדעת את x יחס טרנזיטיבי הושמטו תלויות שחוזרות על עצמן. AUTH i AUTH r private keys

הגנה במערכות מתוכנתות - תרגול 1318 (c) אריק פרידמן 2007 Identity Protection – התקפה אקטיבית initiator responder HDR, SA i   HDR,Sa r HDR, g x i,N i   HDR, g x r, N r HDR*, ID i, [Cert i ], AUTH i   HDR*, ID r, [Cert r ], AUTH r gxr’gxr’ ניתן לפענוח

הגנה במערכות מתוכנתות - תרגול 1319 (c) אריק פרידמן 2007 Denial of Service IKE דורשת חישוב מפתחות DH  פעולה יקרה התקפת DoS: יזום הפעלות רבות של IKE בפרק זמן קצר.  התוקף עצמו יכול להימנע מביצוע חישובי DH בעצמו. בעיה לתוקף משימוש בכתובת IP שלו:  חושף את עצמו.  מותקף יכול להגביל מספר התקשרויות בו-זמניות המותרות מכתובת בודדת.  בד"כ משתמשים בכתובות מקור אחרות (IP Spoofing)

הגנה במערכות מתוכנתות - תרגול 1320 (c) אריק פרידמן 2007 הגנה מפני Denial of Service cookies עוזרים להתגונן מפני DoS עם IP Spoofing.  היוזם נדרש להראות שקיבל את ה-cookie של השרת. initiator(attacker) IP i responder IP r IP x HDR(CKY i ), Sa i, from IP x HDR(CKY i,CKY r ), Sa r, from IP r don’t know CKY r, can’t continue…

הגנה במערכות מתוכנתות - תרגול 1321 (c) אריק פרידמן 2007 הערות מחייב למנוע יכולת ניחוש cookie  בד"כ ה-cookies יחושבו באופן הבא: CKY x = h(IP i, IP r, time, local_secret x ) לא יגן כאשר התוקף משתמש בכתובות IP של רשת בה הוא יושב.  ניתן להתגונן ע"י הגבלת מספר הפעלות IKE ברמת הרשת. לא יגן בפני IP Spoofing דו-כיווני  מורכב מאוד – התקפה זו לא תחשב סבירה בקורס.

הגנה במערכות מתוכנתות - תרגול 1322 (c) אריק פרידמן 2007 תזכורת מבנה IKE  פאזה I: יצירת ערוץ מאובטח המגן על הפאזה השנייה. Main Mode (6 הודעות מועברות) Aggressive Mode (3 הודעות מועברות)  לא מספקת הגנה כנגד DoS ו-Identity Protection. אימות באמצעות סוד משותף (pre-shared secret) אימות באמצעות חתימות  פאזה II: Quick Mode – בניית SA עבור IPsec. נתמקד כעת בפאזה השנייה. שתי דרכי הפעלה מספר דרכי אימות

הגנה במערכות מתוכנתות - תרגול 1323 (c) אריק פרידמן 2007 פאזה שנייה מטרה: הסכמה על IPsec SA. הפאזה מאובטחת ע"י ISAKMP SA  עליו הוסכם במהלך הפאזה הראשונה.  ניתן להשתמש בהפעלה אחת של פאזה ראשונה עבור מספר הפעלות של הפאזה השנייה.

הגנה במערכות מתוכנתות - תרגול 1324 (c) אריק פרידמן 2007 הודעות פאזה שנייה (Quick Mode) המידע לאחר * מוצפן באמצעות SA מפאזה ראשונה (SKEYID e ) HASH i – מחרוזות לאימות ההודעות SA – עבור IPsec – יכיל גם SPI וסוג פרוטוקול (ESP/AH) ID i,ID r – זהויות הצדדים אותם ישמש ה-IPsec עליו מסכימים.  אופציונאלי - למקרה ששונות מאלה שהוחלפו בפאזה הראשונה. initiator responder HDR*, HASH 1, SA, N i, [g x i ], [ID i,ID r ]   HDR*, HASH 2, SA, N r, [g x r ], [ID i,ID r ] HDR*, HASH 3 

הגנה במערכות מתוכנתות - תרגול 1325 (c) אריק פרידמן 2007 חישובים HASH 1 = PRF SKEYIDa (M ID | SA | N i | [g x i ] | [ID i | ID r ] ) HASH 2 = PRF SKEYIDa (M ID | N i | SA | N r | [g x r ] | [ID i | ID r ] ) HASH 3 = PRF SKEYIDa (0 | M ID | N i | N r ) M ID – מזהה של הפעלה מסוימת של Quick Mode. המפתחות עבור IPsec SA: KEYMAT = PRF SKEYIDd ([g x i x r ] | protocol | SPI | N i | N r ) protocol – ESP/AH. המפתח המתאים לכל כיוון שליחה יחושב ע"י ה-SPI של הצד השולח.

הגנה במערכות מתוכנתות - תרגול 1326 (c) אריק פרידמן 2007 שאלה על IKE חברת הי-טק מעוניינת לאפשר לעובדיה להתחבר בעזרת IPsec אל שרתי החברה. העובדים  מתחברים כל אחד לספק ה-Internet החביב עליו (Netvision, אינטרנט זהב, וכיוצ"ב)  מבצעים IKE מול ה-security gateway של החברה.  מאבטחים את כל תעבורת ה-IP שלהם בעזרת IPsec. החברה החליטה כי איננה יכולה לעמוד בהוצאות הכרוכות ברכישת CA, ולכן מנהל הרשת הקצה לכל אחד מהעובדים IKE pre-shared secret. הערה: ספקי אינטרנט מספקים ללקוחות הפונים אליהם כתובות IP זמנית – בכל התחברות מקבל הלקוח כתובת IP חדשה.

הגנה במערכות מתוכנתות - תרגול 1327 (c) אריק פרידמן 2007 שאלה על IKE - המשך 1. הסבר מדוע IKE main mode אינו מתאים לשימוש במקרה זה. 2. הסבר מתי יעדיף משתמש לעבוד עם IKE main mode ולא עם IKE aggressive mode. 3. עקב מצוקת הגיוס של עובדי הי-טק, החלה החברה לנסות לגייס באופן פעיל עובדים ממתחרותיה. מנהלים בחברה נסעו אל אתרים של המתחרות וקיימו פגישות אינטנסיביות (וסודיות) עם עובדיהן של המתחרות. מנכ"ל החברה אסר על המנהלים המגייסים להתקשר אל שרתי החברה כל זמן שהם נמצאים באתרי החברות המתחרות. הסבר מדוע.

הגנה במערכות מתוכנתות - תרגול 1328 (c) אריק פרידמן 2007 שאלה על IKE - המשך 4. אחד המנהלים שלא השלים עם תחושת הניתוק הציע להריץ גרסה מיוחדת של IKE על כל היחידות בחברה שמשתמשות ב- IPsec. הוא הציע לשנות את הגדרת SKEYID עם pre- shared secret authentication בצורה הבאה: SKEYID = PRF Ni | Nr (g x i x r ) 1. האם הגרסה המיוחדת פותרת את בעיית ההתקשרות עם Main Mode? הסבר את תשובתך. 2. הראה התקפה על הגרסה המיוחדת של IKE.

הגנה במערכות מתוכנתות - תרגול 1329 (c) אריק פרידמן 2007 שאלה על IKE - המשך 5. מנהל אחר שהזדהה עם רגשות חברו הציע את השינוי הבא: בנוסף לשינוי החישוב של SKEYID שמוגדר בסעיף ד', תשונה גם צורת חישובים של HASH i ו-HASH r כאשר משתמשים ב- pre-shared secret authentication. דרך החישוב החדשה היא: HASH i = PRF SKEYID | pre-shared-secret (g x i | g x r | CKY i | CKY r | SA i | ID i ) HASH r = PRF SKEYID | pre-shared-secret (g x r | g x i | CKY r | CKY i | SA i | ID r ) 1. האם הגרסה החדשה פותרת את בעיית ההתקשרות ב-Main Mode? הסבר מדוע! 2. האם ההתקפה שתיארת בסעיף ד' 2 אפשרית כעת? הסבר!