Android IKEv2: תעודת המשתמש וה-CA ממלאים תפקידים שונים
שדה אחד מוכיח מי הטלפון, השני מחליט באיזה שער אפשר לתת אמון. פרופיל IKEv2 באנדרואיד מחזיק אותם בנפרד משום שהלחיצה דורשת זאת.
מסך IKEv2 באנדרואיד שמבקש גם תעודת משתמש וגם תעודת CA נראה כאילו הוא מבקש את אותו דבר פעמיים. זה לא כך. IKEv2 מאמת את שני הצדדים בשני הכיוונים בתוך חילוף אחד, והטלפון ממלא תפקיד שונה בכל כיוון: עליו להוכיח מי הוא ולהחליט באיזה שער הוא מאמין. תעודת המשתמש עונה על השאלה הראשונה, ה-CA הנאמן על השנייה, ואף אחד מהם אינו מחליף את האחר.
שני כיווני אימות בחילוף אחד
IKEv2 בונה ערוץ בקרה בשני שלבים. הראשון מנהל משא ומתן על אלגוריתמים ומפתחות; השני, IKE_AUTH, נושא מטען AUTH אחד מכל צד יחד עם הזהות שלו. המטען הוא חתימה או MAC על החילוף, והוא נבדק מול משהו שהמקבל כבר סומך עליו.
השער מוכיח את עצמו בתעודה משלו, והטלפון מאמת את השרשרת עד לשורש שהוא מקבל ובודק שהזהות בתעודה מתאימה לשער שאליו רצה להגיע; הטלפון מוכיח את עצמו באישורים שלו, והשער מאמת אותם מול ה-CA שהוציא את תעודת הלקוח.
זה כל המנגנון שמאחורי שני השדות. תעודת המשתמש היא הצהרה של הטלפון על עצמו; שדה ה-CA הוא הצהרה על במי הטלפון יאמין. פרופיל שיש בו אחד בלי השני אינו משלים אימות הדדי, וניסיון חוזר אינו משנה זאת. גם הכשלים נראים שונים: בלי מפתח משתמש הטלפון אינו יכול לחתום כלל, ובלי עוגן אמון אינו יכול לקבל את תעודת השער.
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
מה בונה הפרופילים של אנדרואיד דורש
בונה פרופיל IKEv2 באנדרואיד מציג כל שיטת אימות בנפרד, ולא כמצב תעודה אחד. שיטת החתימה הדיגיטלית לוקחת תעודת משתמש, מפתח פרטי ו-CA שורש של השרת; האחרות לוקחות שם משתמש וסיסמה, או מפתח משותף מראש.
קראו את החתימה הזו היטב, כי היא מתארת את המנגנון שלמעלה. אין שדה למפתח הפרטי בשיטת שם המשתמש והסיסמה, ואין שדה לעוגן האמון של השער ב-PSK, משום שהשיטות האלה מוכיחות דברים שונים. סיסמה שנדבקה בשדה תעודה יוצרת פרופיל שנכשל ב-IKE_AUTH עם הודעה שאינה נוקבת באף אחד מהם.
סוג המפתח הפרטי המתועד לשיטת החתימה הדיגיטלית הוא RSA. תפריט שכתוב עליו IPsec או תעודה אינו מרמז על תמיכה ב-ECDSA, ופרופיל שנבנה על ההנחה הזו נכשל ב-API של הפלטפורמה עוד לפני שהרשת נכנסת לתמונה.
למה תעודת משתמש ציבורית לבדה אינה מספיקה
מטען ה-AUTH הוא חתימה על החילוף שנעשתה במפתח הפרטי של הלקוח. התעודה הציבורית מאפשרת לשער לבדוק חתימה, אבל אינה עושה דבר עבור הטלפון, שזקוק למפתח כדי ליצור אותה. ייבוא של .crt בלבד והשארת המפתח מאחור הוא הצורה הנפוצה ביותר של כשל זה.
תשתית המפתחות של אנדרואיד משקפת זאת: בחירת זהות לקוח עוברת דרך KeyChain, שדורש גישה למפתח הפרטי המתאים, ולא רק רשומת תעודה. חבילת רישום או תהליך ניהול מכשירים שמתקין את הזוג יחד הוא הדרך הרגילה לזהות שמישה, והעתקה ידנית של קובץ בדרך כלל לא.
לכן שני הפריטים בפרופיל אינם צרור תעודות והעותק שלו. האחד הוא זוג מפתחות שהפלטפורמה חייבת להיות מסוגלת לחתום בו, והשני הוא עוגן אמון שהיא משווה אליו. בדקו אותם כשתי עובדות נפרדות: האם הפרופיל הזה יכול לחתום, והאם הוא יודע במי לבטוח?
עוגני אמון שייכים ליישום, לא לטלפון
שורש שמותקן במאגר המשתמש אינו גורם לכל יישום אנדרואיד לבטוח בו: מאז Android 7 יישום צריך לבחור בכך דרך תצורת אבטחת הרשת שלו, ולפני מהדורה זו תעודות CA שהותקנו בידי המשתמש התקבלו בהרבה יותר רוחב. תצורת האמון יכולה להשתנות בין יישומים, ולקוח VPN שמנהל בעצמו את חומר האמון שלו אולי לא יסתכל במאגר המשתמש כלל. לכן אותו קובץ CA יכול לעבוד בלקוח אחד ולהיראות מתעלמים ממנו באחר.
מכאן שני מודלים של בעלות. פרופיל בניהול המערכת משתמש בהתקנת התעודות של המכשיר או ברישום מנהל, ואז מפנה ל-CA המיועד. VPN בניהול היישום שומר את חומר האמון שלו ואת הייבוא המתועד שלו, שעשוי להיות נפרד לגמרי ממסך ההגדרות של אנדרואיד. שם גם מתקנים שרשרת שבורה.
החליטו באיזה מודל אתם לפני שמייבאים משהו, ואחר כך אשרו את בחירת האמון של הפרופיל הפעיל. אם הוראות המפעיל והתפריט של הלקוח אינם מתיישבים, עבור התקנה זו גובר ההתנהגות המתועדת של הלקוח, אבל ה-CA חייב עדיין לבוא מהמפעיל בערוץ שאתם יכולים לאמת. שם קובץ אינו הוכחה למי הוציא אותו.
קודם המצב, אחר כך הקבצים
מצב התעודה דורש זוג מפתחות של לקוח, את ה-CA המנפיק בצד השער, עוגן אמון לתעודת השער וציפייה איזו זהות התעודה צריכה לשאת. שם משתמש וסיסמה מחליפים את זוג המפתחות באישורים אבל משאירים את דרישת האמון בשער. PSK מחליף את שניהם בסוד משותף ומשנה את מודל האמון במקום לפשט אותו.
מה שתבחרו, השאירו את האימות הרגיל פעיל. אפשרות של בלי לבדוק מסירה את הבדיקה שלשמה קיים שדה ה-CA; היא אינה מתקנת עוגן אמון חסר. כך גם לגבי קבלת כל תעודת שרת מפני שהחיבור עובד בלעדיה.
אחר כך אמתו במקום הנכון: ייבאו את החומר, התחברו פעם אחת, ואשרו בפרטי החיבור שזהות השער היא זו שציפיתם לה ושהפרופיל מדווח על השיטה שהתכוונתם אליה. חיבור מוצלח עם השיטה הלא נכונה הוא תצורה שעוד אינה מובנת לכם, והוא ייכשל כשהמפעיל יקשיח מדיניות.