קרברוס (פרוטוקול)
קרברוס (באנגלית: Kerberos) הוא פרוטוקול אימות ושיתוף מפתח הצפנה, המאפשר ליישומי תקשורת מבוססי שרת/לקוח לאמת זהויות באופן בטוח וכן לנהל תקשורת בטוחה באמצעות מפתחות הצפנה סודיים מעל גבי רשת פתוחה. כיום פרוטוקול זה הוא הפרוטוקול הנפוץ ביותר לאימות, שלמות המידע וסודיותו. הפרוטוקול הוא חלק מחבילת תוכנה חופשית שפותחה על ידי MIT המשתמשת בפרימיטיבים קריפטוגרפיים שונים ומיישמת בין היתר את הפרוטוקול בעיקר כמודל שרת-לקוח. הפרוטוקול מאפשר גם אימות זהויות הדדי, בו הלקוח והשרת יכולים לאמת זה את זהותו של זה. פרוטוקול קרברוס מסתמך על הצפנה סימטרית בלבד ודורש סיוע של צד שלישי נאמן. מהלכי הפרוטוקול מוגנים מפני ציתות והתקפת שידור חוזר. לעומת פרוטוקול סיסמה רגיל הנקרא "אימות חלש", פרוטוקול קרברוס מציע מה שמוגדר "אימות חזק", כיוון שהוא מערב הצפנה כדי להגן על מפתחות ההתקשרות מפני ציתות בזמן העברתם.
היסטוריה והתפתחות
פרוטוקול קרברוס נולד כחלק מפרויקט אתנה (Athena Project), שמו ניתן לו על שם הדמות קרברוס מהמיתולוגיה היוונית, מפלצת דמוית כלב, בעלת שלושה ראשים ששירתה את האדס - "אליל השאול", בשמירה על שער הגיהנום.
פרויקט אתנה הוקם על ידי MIT ב-1979 במטרה לספק הגנה על רשת המחשבים הפנימית של המכון. לאפשר גישה למחשבי המכון על ידי המשתמשים המורשים ולמנוע גישה לקבצים פרטיים ממי שלא הוסמך לכך. בשלבים הראשונים פותחו שלוש גרסאות פנימיות של הפרוטוקול שלא פורסמו. גרסה 4 שמפתחיה העיקריים היו סטיב מילר וקליפורד ניומן פורסמה במחצית השנייה של 1980 ונועדה בעיקר לצורך הפרויקט. לאור ליקויים שהתגלו בה, פותחה גרסה 5 של הפרוטוקול[1] על ידי צוות של MIT בראשות קליפורד ניומן וג'ון קול ופורסמה בספטמבר 1993. גרסה זו הורחבה מספר פעמים במטרה לתקן מספר ליקויי בטיחות שהתגלו לאורך השנים בגרסה המקורית. MIT שחררה את גרסה 5 של הפרוטוקול לשימוש חופשי ופרסמה מימוש שלו לחלונות ולמקינטוש תחת היתר שימוש הדומה למערכת ההפעלה BSD וכן פרסמה את ממשק תכנות יישומים (API) עבור קרברוס הנקרא GSS-API המאפשר קריאות לפונקציות קריפטוגרפיות לצורך הפרוטוקול.
מבחינה היסטורית, בשל העובדה שמימוש הפרוטוקול כולל אלגוריתם הצפנה כמו DES שהעיסוק בו נחשב בעבר לפי החוק האמריקאי כעיסוק בנשק או תחמושת (כמו טנק או טיל בליסטי), הוכנס הפרוטוקול לרשימת אמצעי החימוש האסורים ביצוא מחוץ לתחומי ארצות הברית. לפני שינוי תקנות הייצוא הקריפטוגרפיות של ממשלת ארצות הברית, פותחה בשוודיה גרסה חופשית של פרוטוקול קרברוס הנקראת Heimdal על בסיס גרסה מוגבלת של MIT (שממנו הוסרו האלמנטים הקשורים בהצפנה) וכן פותחה גרסה נוספת של הפרוטוקול בשם Shishi תחת רישיון שימוש GPL של GNU.
אלגוריתמים נתמכים
הצפנים הסימטריים שהיו בשימוש הפרוטוקול בעבר הם DES במצב הפעלה CBC וצופן הזרם RC4 והאימות בוצע עם קוד אימות HMAC בשילוב פונקציית הגיבוב MD5. כיום קיימת תמיכה להצפנה מאומתת עם AES בשתי גרסאות: AES128-CTS-HMAC-SHA1-96 וכן AES256-CTS-HMAC-SHA1-96.
שימושים
קרברוס אינו מתאים לשימוש ברשת האינטרנט אלא בעיקר ברמה ארגונית. החל מחלונות 2000 ומעלה, אימצה חברת מיקרוסופט את פרוטוקול קרברוס גרסה 5 כברירת המחדל לביצוע תהליכי אימות זהויות של Active Directory בכל גרסאות מערכות ההפעלה מבית החברה, כולל קונסולות Xbox. מיקרוסופט אינה משתמשת במימוש של MIT אלא תחת זאת בגרסה שונה במעט שהם פיתחו שנקראת SSPI. טכנולוגיות מבית חברת SAP כמו CyberSafe מיישמות את מימוש MIT של קרברוס. מערכות הפעלה רבות תואמי יוניקס תומכות בפרוטוקול קרברוס, בהן Red Hat, מערכת ההפעלה FreeBSD, מערכת ההפעלה Mac OS X של אפל על מחשבי מקינטוש, סולאריס ועוד.
יעדי הפרוטוקול
קרברוס פותח במטרה לספק אימות מהימן בין משתמשים ברשת תקשורת פתוחה שבה אפשר לצותת לחילופי המסרים וליירטם. הצלחת הפרוטוקול תלויה באמינות המחשבים המשתתפים בתקשורת. שרתי האימות, ספקי השירותים והלקוחות חייבים להיות בטוחים ומעודכנים באופן כזה שלא יכילו פרצות כך שניתן יהיה להבטיח את תהליך האימות. במילים אחרות, פרוטוקול קרברוס הוא פרוטוקול אימות בין מחשבים אמינים ברשת לא אמינה. אם מישהו מצליח לפרוץ לאחד המחשבים המשתתפים בפרוטוקול אין כל תועלת בו, לכן הנחת היסוד של הפרוטוקול היא שכל המשתתפים "הגונים". יעדי הפרוטוקול הם:
- סיסמת המשתמש לעולם לא תשודר באופן גלוי ברשת.
- סיסמת המשתמש לעולם לא תשמר במחשב הלקוח אלא תושמד מיד לאחר השימוש בה.
- סיסמת המשתמש לעולם לא נשמרת במצב גלוי, גם לא במסד הנתונים של שרת האימות.
- המשתמש נדרש להקיש סיסמה רק פעם אחת בתחילת השיחה.
- ניהול מידע האימות של כל הלקוחות מרוכז במקום אחד. ספק השירותים או שרת היישומים לא אמור להכיל כל מידע אימות של לקוחותיו. עובדה זו מאפשרת למנהל הרשת לעדכן סיסמת משתמש או לבטל משתמש בפעולה אחת ללא צורך בעדכון שרתים נוספים. בנוסף לכך שמספר המקומות המכילים מידע אימות סודי קטן ככל האפשר.
- לא רק הלקוחות אלא גם השרתים ייתכן שיידרשו לאמת עצמם מול הלקוחות, מה שקרוי אימות דו צדדי.
- בגמר האימות וההרשאה, הלקוח והשרת יוכלו להתחיל בקישור מוצפן. לשם כך הפרוטוקול מספק תמיכה ישירה ביצירה והחלפה של מפתחות הצפנה סודיים.
הגדרות כלליות
- תחום (Realm) מייצג את גבולות תחום האימות בו שרת האימות רשאי או יכול לאמת לקוחות, שרתים או מארחים. אין הכוונה שהלקוח והשרת חייבים להיות באותו תחום כדי שיצליחו להתקשר ביניהם, ייתכן מצב שבו שרת מאמת לקוח מתחום אחר אם קיים יחס אימון בין התחומים, אך תמיד לקוח משתף סוד רק עם מנהל התחום בו הוא נמצא. לכל תחום יש שם ובדרך כלל הוא זהה ל-DNS באותיות רישיות.
- פרינציפל (Principal) מתייחס לכניסה במסד הנתונים של שרת האימות המכילה את שמו של המשתמש, המארח או השרת המשויך אליה. מבנה השדה הוא:
- Name[/Instance]@REALM.
- כאשר Instance אופציונלי ומייצג את סוג המשתמש. לדוגמה host/[email protected].
- טיקט (Ticket) היא חבילת נתונים אותה הלקוח מציג בפני שרת היישומים או ספק השירותים על מנת לזהותו לצורך התחברות או מתן שירות. טיקטים מונפקים על ידי שרת האימות והם מוצפנים עם מפתח סודי המשותף לשרת האימות וספק השירות. הלקוח עצמו אינו יכול לראות את תוכן הטיקט, אלא רק להעבירו לשרת המתאים. טיקט מכיל בעיקר את שם מבקש השירות, שם נותן השירות, כתובת IP של מחשב הלקוח (אופציונלי), תאריך הנפקה, תאריך תפוגה ומפתח שיחה. כל טיקט בתוקף לזמן מוגבל (בדרך כלל 10 שעות) בגלל שמרגע שהונפק הטיקט לא ניתן לבטלו. טיקטים בדרך כלל מכילים מידע נוסף בצורת דגלים.
- הצפנה. כחלק מתהליכי הפרוטוקול נדרשת מעת לעת הצפנה של מסרים כמו טיקטים אישורים וכדומה. בעיקרו פרוטוקול קרברוס סימטרי במובן שכל שתי נקודות המשתפות מידע סודי ביניהן חובה עליהן לשתף תחילה מפתח סודי זהה. אם כי תהליכים מסוימים של קרברוס בעיקר בשלב האתחול יכולים להשתמש גם בתשתית מפתח ציבורי PKI עם סרטיפיקט X.509. סוגי ההצפנה משתנים בהתאם לגרסאות והם נפרדים מהפרוטוקול. גרסה 4 של קרברוס עשתה שימוש ב-DES אך בשל חולשות הקיימות באלגוריתם ההצפנה וגם כאלו שהתגלו בפרוטוקול עצמו היא הוצאה מכלל שימוש. הגרסה הנוכחית היא קרברוס 5 גרסה 1.3 המאפשרת מגוון רחב של סוגי הצפנות לפי העדפה וכדי למנוע בעיות תפעוליות הנובעות מריבוי גרסאות ישנם אלגוריתמים מנדטוריים שכולם חייבים לספק להם תאימות. קיימת פרצה שנובעת מהעובדה שבגלל ההבדלים הגדולים בין מערכות הפעלה כמו לינוקס וחלונות, האלגוריתמים שקיימת לגביהם תמיכה חוצת מערכות חלשים מדי כמו DES עם מפתח באורך 56 סיביות או אלגוריתם RC4-HMAC.
- מפתח הצפנה. המטרה העיקרית של הפרוטוקול היא כאמור להימנע ממצב שסיסמת המשתמש תאוחסן או תשודר באופן גלוי. מהלכי הפרוטוקול אם כן נדרשים להיות מוצפנים באמצעות מפתחות הצפנה שונים ובאורכים שונים בהתאם לצורך. מטעמי ביטחון יש צורך במרבית המקרים להפריד לגמרי בין נתונים מוצפנים כך שכל אחד מהם יוצפן עם מפתח אחר. היות שלא מעשי לכפות על המשתמש לספק סיסמאות חדשות בכל פעולת התחברות, אין אפשרות להשתמש בסיסמה עצמה כמפתח הצפנה תחת זאת, מופעלת פונקציה מתאימה בדרך כלל פונקציית גיבוב קריפטוגרפית כדי להמיר את הסיסמה למפתח הצפנה ראוי. אם פונקציית הגיבוב בטוחה, אז מלבד כוח גס גם אם מפתח ההצפנה נופל לידי האויב או המתחרה הוא לא יצליח לגלות באמצעותו את הסיסמה.
- מלח (Salt). היא מחרוזת שם התחום אותה מוסיפים לפונקציה המייצרת מפתח הצפנה מהסיסמה. הרעיון הוא שבנוכחות מחרוזת המלח גם אם למשתמש סיסמה קבועה לתחומים שונים (מה שבדרך כלל קורה) מפתח ההצפנה שייווצר יהיה שונה. משתמשים בדרך כלל מעדיפים לזכור סיסמה אחת ולהשתמש בה בכל מקום שנדרש אימות. משיקולי ביטחון רצוי להימנע ממצב שמפתח ההצפנה המופק עבור משתמש אחד לתחומי רשת שונים, למשל חיבור לשרת קרברוס ו/או חיבור לשרת אחר, יהיה זהה. לצורך תאימות עם גרסאות ישנות אפשר לספק מחרוזת מלח ריקה. יש לציין שמלח רלוונטי רק למשתמשי קצה אנושיים ופחות רלוונטי לשירותים הנגשים לשירותים אחרים כי במקרה זה אין מי שיקליד סיסמה.
- מספר מפתח. לצורך מעקב, כאשר משתמש מחליף סיסמה או כאשר מנהל הרשת מעדכן מפתח סודי של שירות או שרת, השינוי מעודכן על ידי קידום מונה. הערך הנוכחי של המונה מייצג את גרסת המפתח המסומן בקיצור KVNO.
מרכז הפצת מפתחות
פרוטוקול קרברוס הוא גם פרוטוקול שיתוף מפתח המבוסס על פרוטוקול נידהאם-שרודר (Needham & Schroeder) עם שיפורים שהוצעו על ידי Denning & Sacco. הרעיון הוא להסתייע בשרת ייעודי המכונה KDC קיצור של Key Distribution Center שתפקידו לייצר מפתחות הצפנה זמניים לצורך הצפנת שיחות בין הלקוחות ושרתים או בין שרתים. פרוטוקול קרברוס מכיל גם הגדרה לשרת ניהול הנקרא KADM שתפקידו לנהל את רשימת המפתחות הסודיים ארוכי הטווח של כל המשתמשים, להוסיף או למחוק משתמש לפי הצורך.
KDC של קרברוס הוא שרת אימות המייצר תעודות אימות איתם הלקוחות יכולים לזהות עצמם ולקבל את השירות המבוקש. למרות ההתייחסות אליו כאל ישות אחת הוא למעשה מורכב משלושה חלקים (כמתואר בתרשים למעלה): מסד נתונים, שרת אימות (AS) ושרת הנפקת טיקטים (TGS). מעשית הפרוטוקול מיושם בדרך כלל במחשב אחד המכיל את כל הגופים.
- מסד הנתונים מכיל כניסות הנקראות פרינציפלים המשויכים למשתמשים, שרתים, מארחים ונותני שירותים למיניהם. לכל כניסה מודבק שם והיא כוללת מספר נתונים חשובים: שם המשתמש, מפתח הצפנה ומספר סידורי, משך תקפות הטיקטים ומקסימום הזמן שניתן לחדשן, תאריך תפוגת הסיסמה או חברות המשתמש ומאפיינים נוספים בצורת דגלים. כל הנתונים במאגר כולל גיבויים ונתונים זמניים כמו מטמון מוצפנים עם מפתח הצפנה של מנהל ה-KDC הנקרא "מפתח מאסטר".
- AS הוא שרת אימות והוא זה שמגיב לבקשת הלקוח לראשונה. זהו גם השלב היחיד שבו המשתמש נדרש להקליד סיסמה. מאחורי הקלעים, שרת האימות מוודא תחילה שהמשתמש אכן מי שהוא טוען שהוא, אם כן הוא מנפיק עבורו טיקט מיוחד הנקראת Ticket Granting Ticket או בקיצור TGT. רק עם טיקט זה הלקוח יכול להתקשר עם שרת ה-TGS.
- TGS הוא שרת יישומים הממוקם בין שרת האימות לבין נותן השירות והוא אחראי להנפקת טיקט שירות תקף ללקוח המציג TGT תקף. שרת ה-TGS אחראי להבטיח שזהות הלקוח אושרה לפני שהוא מנפיק תעודת שירות עבור נותן השירות המבוקש. יש להבדיל בין TGT הנקרא "טיקט להנפקת טיקט" שתפקידו רק להעביר את הטיפול משרת האימות לשרת ה-TGS לבין טיקט שירות שהוא טיקט שניתן לאחר שהמשתמש אומת ונועד להתחברות או לקבלת שירות מנותן השירות.
מפתח שיחה
ערך מורחב – מפתח שיחה
המפתחות המשותפים לשרתים והלקוחות (מפתח סודי המשותף לשרת האימות והלקוח שנגזר מסיסמת הלקוח ומפתח אחר המשותף לשרת האימות ונותן השירות שנקבע על ידי מנהל הרשת) נקראים מפתחות ארוכי טווח כי הם קבועים ואינם משתנים לאחר שיחה אחת. היות שאין קשר בין המפתחות, הלקוח אינו יכול להתקשר עם נותן השירות ללא קיומו של מפתח משותף נוסף להצפנת התקשורת ביניהם לפחות למשך הזמן השיחה. מפתח זה המונפק על ידי ה-KDC כחלק מהטיקט נקרא מפתח שיחה. מפתח השיחה מונפק בשני עותקים, עותק אחד מיועד לנותן השירות והוא "נעטף" על ידי ה-KDC בתוך הטיקט באופן כזה שללקוח עצמו אין גישה אליו אלא רק נותן השירות המתאים שמחזיק במפתח ארוך טווח המשותף לו ולשרת האימות. העותק השני המיועד ללקוח עצמו והוא "נעטף" בנפרד בחבילה המוצפנת באמצעות המפתח הנגזר מסיסמת המשתמש. כך שלמשתמש היכולת לפענח את החבילה המיועדת אליו ולחלץ את המפתח השיחה מתוכה. למפתח שיחה תפקיד חשוב בסביבת קרברוס.
תעודת אימות
קיומו של טיקט שירות תקף (בקיצור טיקט) עדיין אינו משליך בהכרח על אימות הלקוח. היות שמדובר ברשת פתוחה, כל אחד יכול ליירט טיקט ולנסות לעשות בו שימוש מאוחר יותר. קיומה של כתובת IP לא עוזרת במיוחד כיוון שכידוע קל לזייף כתובות. הדבר היחיד שהלקוח ונותן השירות יודעים ואף אחד אחר לא, הוא מפתח השיחה (כמובן בנוסף למנהל הרשת שהכין אותו, אבל הוא בהגדרה נקרא "נאמן"), לכן האסטרטגיה שנוקט פרוטוקול קרברוס היא: יחד עם הטיקט שהלקוח שולח לנותן השירות הוא מצרף תעודת אימות (authenticator) בה מופיעים פרטי הלקוח וחותם זמן כשהם מוצפנים באמצעות מפתח השיחה. נותן השירות מצידו פועל בדרך מאוד פשוטה, תחילה הוא מחלץ את המפתח השיחה מהטיקט המיועד אליו, איתו הוא משתמש כדי לפענח את תעודת האימות. אם הלקוח הוא באמת מי שהוא טוען שהוא, השרת יוכל לפענח את התעודה בהצלחה ולחלץ את פרטי הלקוח ולבדוק שאכן זמן הנפקת התעודה "טרי". תעודה שעבר זמנה כלומר שהזמן המופיע בה רחוק לפחות שתי דקות מהזמן בשעונו של השרת תדחה מיד. כאן רואים מדוע יש חשיבות לסינכרון הזמן בין השעונים של מחשבים השייכים לאותו תחום.
קיימת אפשרות קלושה שהמתקיף יצליח ליירט טיקט ותעודת אימות ולשלוח אותם בתוך פחות משתי דקות או כל חלון זמן אחר שהוגדר על ידי המערכת. הפתרון שנוסף בגרסה 5 הוא "מטמון שידור חוזר" (Replay cache). בעיקר בשרתים, נוספה אפשרות למעקב אחרי כל התעודות שהתקבלו במשך חלון הזמן שנקבע, והמערכת יודעת לדחות תעודות כפולות ובכך למנוע התקפת שידור חוזר מסוג זה. הבעיה תיפטר בתנאי שהמתקיף המתוחכם לא יצליח לשלוח את התעודה והטיקט הגנובים לפני שהלקוח עצמו הספיק לעשות זאת. זה כמובן יהיה משעשע כי הלקוח הלגיטימי עלול להיות מואשם ב"התחזות".
הרשאות
היות שהלקוח לעולם אינו שומר את סיסמתו במחשב (או לפחות זו ההמלצה), כדי להתאים את המערכת למצב של "אימות יחיד" (בכניסה) הנקרא בקיצור SSO, יש צורך לשמור במקום זמני כלשהו את מפתח השיחה והתעודות לפחות עד שהשיחה מסתיימת. המקום בו מאוחסן המידע הזה נקרא מטמון הרשאות (Credential Cache). מיקום המטמון אינו תלוי בפרוטוקול והוא משתנה מיישום אחד לאחר לפי העדפה. במימוש של MIT לצורך תאימות מטמון ההרשאות נשמר במערכת הקבצים. להגברת הביטחון יש כאלו (כמו Active Directory של מיקרוסופט) שמאחסנים אותו בזיכרון הליבה המוגן מפני גישה ברמת משתמש ואינו מועתק למקום אחר בזמן שהמערכת מדפדפת.
טרמינולוגיה
| שם | תיאור |
|---|---|
| Service | שירות; משאב רשת כגון חשבון משתמש, שירות הדפסה, שרות קבצים או חשבון דואר אלקטרוני. |
| User | משתמש; בדרך כלל משתמש אנושי המעוניין בקבלת השירות או בגישה למשאב מרוחק. |
| Client | לקוח; מחשב המייצג את המשתמש. בעת הניסיון לגשת אל המשאב המרוחק המחשב דורש מהמשתמש להקליד את שמו וסיסמתו. לקוח יכול להיות גם גורם לא אנושי כגון שרת המבקש להתחבר לשרת אחר ומכונה Daemon. |
| Service Server | שרת השירות; שרת המספק שירותים כגון אילו המנויים לעיל, אליו הלקוח מנסה להתחבר על מנת לקבל את השירות המבוקש. לשרת זה אין גישה למסד הנתונים המוצפן המכיל מידע על הלקוחות. |
| Ticket | טיקט; חבילת מידע המשודרת ברשת, הכוללת נתונים (חלקם מוצפנים) המאפשרים לשרת השירות לאמת את זהות הלקוח ולאפשר לו גישה לשירות או המשאב המבוקש. |
| Ticket Granting Server (TGS) | שרת להנפקת טיקטים; שרת קרברוס ייעודי המנפיק טיקטים ללקוחות שברצונם להתחבר לשרת השירות האמור. |
| Authentication Server (AS) | שרת אימות; שרת קרברוס ייעודי שתפקידו לאמת זת זהות הלקוחות ולקשר בינם לבין שרת הנפקת טיקטים. לשרת זה גישה למסד הנתונים המוצפן. |
| Ticket Granting Ticket (TGT) | טיקט להנפקת טיקטים; טיקט שאיתו הלקוח מאמת את זהותו מול שרת TGS על מנת לקבל ממנו טיקט שירות להתחברות לשרת השירות. לשרת זה גישה למסד הנתונים המוצפן. |
| Timestamp | חותם זמן ; ערך המייצג את הזמן המקומי בשעון הלקוח בעת הגשת הבקשה. במהלך הפרוטוקול נבדק זמן הגשת הבקשה על מנת לוודא כי הטיקט עדיין תקף. |
| Network Address | כתובת רשת; כתובת IP של מחשב הלקוח ברשת האינטרנט. |
| Session Key | מפתח שיחה; מפתח הצפנה חד-פעמי המתאים להתקשרות יחידה או לפרק זמן קצר. מפתח-שיחה משמש בדרך כלל למשך שיחה אחת אם כי בפרוטוקול קרברוס המפתח יכול לשמש למספר שיחות. |
הערה: הסוגריים המסולסלים בתרשים ובתיאור הפרוטוקול להלן מייצגים את חלק המידע המוצפן כאשר מפתח ההצפנה מצוי מיד לאחריהם בליווי סוגריים המציינים את השותפים למפתח (הגורמים שהמפתח ידוע להם). יתר חלקי המידע מועברים באופן גלוי.
תיאור מהלכי הפרוטוקול
1. המשתמש מקיש שם משתמש וסיסמה בצד הלקוח. הלקוח (המחשב) מבצע פונקציית גיבוב חד כיוונית על הסיסמה שהוקלדה והתוצאה המתקבלת מהווה מפתח סודי של הלקוח.
2. הלקוח שולח בשמו של המשתמש מסר קריא לשרת האימות (AS) לקבלת המלצה (credential) עבור שירות או גישה למשאב מסוים מספק השירות, בנוסח: "משתמש פלוני מבקש לקבל שירות מספק פלוני". שימו לב שהלקוח אינו נדרש לשלוח סיסמה או מפתח סודי כלשהו לשרת האימות.
3. שרת האימות מזהה את הלקוח ברשימותיו על פי טענת זהותו. אם הלקוח האמור אכן מופיע ברשימותיו, שרת האימות מחזיר לו המלצה המורכבת משני מסרים מוצפנים:
מהלך 1: שרת אימות ללקוח (המלצה)
- TGT: {זהות, כתובת, תוקף, מפתח-שיחה(לקוח/TGS)}מפתח(TGS)
- תעודה הכוללת את זהות הלקוח, כתובת הרשת של הלקוח, תוחלת הזמן של התעודה ומפתח-שיחה טרי לשימוש בינו ובין שרת TGS. כשהיא מוצפנת באמצעות מפתח הצפנה הידוע רק לשרת TGS.
- {מפתח-שיחה(לקוח/TGS)}מפתח(לקוח)
- מפתח שיחה טרי להתקשרות בינו לבין שרת TGS, המוצפן באמצעות מפתח ההצפנה שנגזר מסיסמת המשתמש.
4. אם הלקוח לגיטימי, הוא משתמש במפתח הסודי שברשותו כדי לפענח את המסר השני המיועד אליו כדי לחלץ ממנו את מפתח השיחה, בעזרתו הוא יתקשר לאחר מכן לשרת TGS. (שימו לב שהלקוח אינו מסוגל לפענח את המסר הראשון שקיבל כיוון שהוא מוצפן באמצעות מפתח סודי הידוע רק לשרת ה-TGS). אם הלקוח אינו לגיטימי, כגון אם הוא מתחזה, אין במידע שקיבל כל תועלת כיוון שהוא מוצפן וההנחה היא כי מפתח ההצפנה ידוע אך ורק ללקוח הלגיטימי. בשלב זה בידי הלקוח מספיק נתונים כדי לאמת את זהותו מול שרת ה-TGS.
5. כדי לקבל את השירות המבוקש, תחילה הלקוח מבקש בשם המשתמש משרת קרברוס TGS תעודת התחברות, על ידי שליחת המסרים הבאים:
מהלך 2: לקוח לשרת הנפקת תעודות
- TGT: שירות, {לקוח, כתובת, תוקף, מפתח-שיחה(לקוח/TGS)}מפתח(TGS)
- התעודה להנפקת תעודות שקיבל משרת האימות במהלך הקודם ואת פרטי השירות המבוקש (כתובת או זהות ספק השירות או המשאב). וכן:
- Authenticator: {לקוח, חותם-זמן}מפתח(לקוח/TGS)
- מזהה או מאמת הכולל את זהות הלקוח וחותם זמן, כשהם מוצפנים באמצעות מפתח השיחה שקיבל זה עתה משרת AS (שרת ה-TGS מקבל את המפתח כחלק מהתעודה המוצפנת).
- הצורך במזהה נובע מהעובדה כי התעודה לבדה אינה מספקת הוכחה כי הלקוח הוא אותנטי. מתחזה עשוי להעתיק תעודה ישנה ולנסות להשתמש בה כדי להתחזות ללקוח הלגיטימי. המזהה מונע אפשרות כזו על ידי הצפנה של זמן הגשת הבקשה באמצעות מפתח השיחה. היות שמפתח השיחה ידוע רק למשתמש הלגיטימי, כי המפתח הגיע אליו מוצפן, ניתן להווכח בוודאות שהבקשה אינה מגיעה ממתחזה וכי היא בקשה טרייה.
6. עם קבלת המסרים, שרת ה-TGS מפענח את ה-TGT שקיבל באמצעות המפתח הסודי שלו, מחלץ את מפתח-השיחה ובודק: שהתעודה עדיין תקפה, שפרטי הלקוח תואמים את המידע שהתקבל קודם ושהמשתמש בעל הרשאה לשירות המבוקש. אם כל הנתונים תקינים אזי ה-TGS מפיק עבורו תעודה להתחברות לספק השירות ושולח ללקוח את המסרים הבאים:
מהלך 3: שרת הנפקת תעודות ללקוח
- Ticket(לקוח/שרות): שירות, {לקוח, כתובת, תוקף, מפתח(לקוח/שרות)}מפתח(שירות)
- תעודה הכוללת את זהות הלקוח, כתובת הרשת של הלקוח ותוחלת הזמן של התעודה ומפתח שיחה טרי, המוצפנת באמצעות המפתח הסודי של ספק השירות. וכן:
- {מפתח(לקוח/שירות)}מפתח(לקוח/TGS)
- מפתח השיחה לשימוש בין הלקוח והשרת, מוצפן באמצעות מפתח השיחה המשותף לו ול-TGS.
7. כאשר הלקוח מקבל את המסרים הללו משרת ה-TGS בידיו מספיק נתונים כדי לאמת את זהותו מול ספק השירות. הלקוח מתחבר לשרת השירות ושולח לו את המסרים הבאים:
מהלך 4: לקוח לספק שירות
- Ticket(לקוח, שירות): שירות, {לקוח, כתובת, תוקף, מפתח(לקוח/שירות)}מפתח(שירות)
- התעודה שקיבל משרת הנפקת התעודות במהלך הקודם המוצפנת באמצעות המפתח הסודי של ספק השירות.
- Authenticator: {לקוח, חותם-זמן}מפתח(לקוח/שירות)
- מזהה חדש הכולל את פרטי זהות הלקוח וחותם-זמן טרי המוצפנים באמצעות מפתח השיחה החדש.
8. ספק השירות מפענח את התעודה באמצעות המפתח הסודי שלו מחלץ את מפתח השיחה ומפענח את ה'מזהה' שקיבל ובודק את המידע הכלול בו. אם הכל כשורה הוא מאשר את בקשת ההתחברות מאפשר ללקוח גישה לשירות המבוקש.
9. אופציונלית לצורך אימות הדדי, השרת שולח ללקוח את חותם הזמן הטרי שהתקבל במהלך 3 וכן מפתח שיחה חדש (אם יש צורך), מוצפנים באמצעות מפתח השיחה המשותף. הלקוח מפענח את מסר האחרון ומוודא שחותם הזמן מתאים לחותם הזמן שהוא שלח. אם כן הלקוח יכול לסמוך על השרת ויכול להשתמש בשירות המבוקש.
סיכום מהלכי הפרוטוקול: הלקוח מקבל משרת האימות המלצה שאיתה הוא מוכיח לשרת הנפקת התעודות שהוא מוסמך לקבלת תעודת השירות המבוקשת ומקבל אותה, באמצעותה הוא מוכיח לאחר מכן לספק השירות שזהותו אומתה וכי הוא רשאי לקבל את השירות המבוקש ומקבל אותו.
בטיחות ויעילות
ניהול מפתחות
פרוטוקול קרברוס מחייב את הלקוח והשרת במהלך הפרוטוקול להחזיק במפתח הצפנה ומפתח שיחה לפיענוח מסרי הפרוטוקול במצב קריא (לא מוצפן). עובדה זו יוצרת נקודת תורפה מסוימת, אם תוקף פוטנציאלי מצליח לחדור למערכת ולחלץ את המפתחות הללו, הוא יוכל להתחזות ללקוח ללא כל בעיה. בנוסף שרתי KDC אמורים לנהל מסד נתונים המכיל מידע על זהות המשתמשים והמפתחות הסודיים שלהם (הסיסמאות). מידע זה חייב להיות מוגן באמצעים קריפטוגרפיים. כמו כן התכנון הראשוני של הפרוטוקול מחייב את שרתי קרברוס לאחסן בקשות אחרונות על מנת למנוע התקפות שימוש חוזר. מימוש זה בעייתי בפלטפורמות מסוימות. השימוש באתגר/מענה מבטל את הצורך הזה.
אם לתוקף פוטנציאלי יש גישה לערוץ התקשורת בו מתנהל הדו-שיח בין השרת ללקוח, הוא יכול לאסוף מספר גדול של תעודות מוצפנות שנשלחו. בגרסה הבסיסית של הפרוטוקול לא הוגדרה שיטה מעשית להצפנת תהליך האימות. בשיטה הרגילה התעודות מוצפנות באמצעות המפתח הסודי של המשתמש שנגזר מהסיסמה שלו באמצעות פונקציה ציבורית מוסכמת. על כן התוקף יכול לנסות לפענח את התעודות באופן לא מקוון על ידי ניסיון לנחש את הסיסמה ולבדוק האם מפתח ההצפנה מתאים. לכן השימוש בפרוטוקול זה אינו פותר את המשתמשים מהצורך להחזיק בסיסמאות חזקות כלומר קשות לניחוש (ראו סיסמה).
התקפת שימוש חוזר - Replay attack
כדי למנוע התקפת שימוש חוזר, שבה התוקף מנסה להתחזות ללקוח הלגיטימי על ידי שידור חוזר של מסרי הפרוטוקול מתהליך ישן. פרוטוקול קרברוס עושה שימוש במזהה המכיל חותם-זמן. חותם הזמן מאפשר לאכוף טריות ובכך לסכל ניסיון שימוש בבקשות ישנות. על כן סינכרון הזמן בין השרת והלקוח, הוא תנאי הכרחי בפרוטוקול קרברוס. מקובל לאפשר סטייה קלה (בדרך כלל כ-5 דקות), בין הזמן שמקורו בשעון הלקוח לבין הזמן בשעונו של השרת, בזמן קבלת הבקשה. בכל מקרה שהפרש הזמן עולה על שיעור סטייה שנקבע מראש, הבקשה נדחית.
שירות זמן מאובטח
הצורך בסינכרון הזמן בגרסה הבסיסית, מטיל מגבלה על מימוש הפרוטוקול ומהווה חיסרון משמעותי. אם הזמן בשעון השרת מוטעה ניתן יהיה לעשות שימוש במזהה ישן ובכך להתחזות ללקוח לגיטימי ללא בעיה. על כן יש צורך להגן על שעון השרת מפני שינויים חיצוניים על ידי תוקף פוטנציאלי. מלבד זאת כיוון שבטיחות הפרוטוקול תלויה בזמן, תהליך הסנכרון עצמו חייב להיות בטוח. אולם סנכרון שעון בטוח הוא בעיה קריפטוגרפית כשלעצמה. קיימת גרסה שונה של הפרוטוקול ללא שימוש בחותם זמן במחיר של מהלך נוסף.
צד שלישי
התלות בצד שלישי מקוון מגביל את השימוש בפרוטוקול ומחייב כי שרת הצד השלישי יהיה זמין בעת הרצת הפרוטוקול. אם שרת קרברוס קורס, גורם הדבר להשבתה של כל מערכת האימות. כדי למנוע מצב כזה, בדרך כלל מערכת אימות כוללת מספר שרתי אימות של קרברוס.
יתרונות וחסרונות
לפרוטוקל זה מספר יתרונות:
- מאובטח יותר.
הסיסמאות לא עוברות ברשת אף פעם.
לעומת NTLM (בה הסיסמה לא מוצפנת מהשלב הראשון בתהליך), ב-Kerberos מתבצעת פונקציית גיבוב כבר בהודעה הראשונה, כך לא ניתן לראות את הסיסמה גלויה בעקבות פריצה לוקאלית.
פונקציות הצפנה חזקות יותר מ-NTLM.
תיקון החולשות הקיימות ב-NTLM.
- ביצועים טובים יותר.
יחס מהירות/אבטחה גבוה וטוב - לפי יחס זה, ככל שהאבטחה שלי יותר טובה כך גם התהליך יותר איטי, ולהפך - ככל שהאבטחה שלי פחות טובה התהליך מהיר יותר. Kerberos יודע לאזן בין האבטחה למהירות הביצוע, לעומת NTLM שם המהירות גבוהה, אך האבטחה בינונית.
- אימות דו-צדדי
Kerberos תומך ומספק אימות דו-צדדי - כלומר לא רק שהלקוח מתאמת מול השרת/השירות אלא גם השרת/השירות מתאמתים מולו.
אימות דו-צדדי הוא אופציה שהלקוח יכול לדרוש מהפרוטוקול Kerberos.
- Delegation (נקרא גם authentication forwarding)
הודות ל"האצלת הסמכויות" שיש ל-Kerberos, שירות שהמשתמש ניגש אליו יכול לגשת מרחוק למשאבים בשהוא צריך בשם הלקוח. כלומר, משתמש א' יכול לתת את הזכות לתחנה ב' לאמת את עצמו מול אפליקציה שנמצאת בשרת ג' כאילו תחנה ב' היא המשתמש א'. שיטה זו יעילה מאוד, לעומת התחברות לשרת ג'.
NTLM תומך רק ב-impersonating - שיש צורך ב"דיבור ישיר" של אותו לקוח והתחברות למשאבים חדשים.
NTLM עובד בתצורת אתגר/מענה ולכן מספק אימות חד-צדדי בלבד. זהו אחד ההבדלים העיקריים בפרוטוקול.
לפרוטוקול יש שני חסרונות עיקריים. הראשון הוא הפרוטוקול חשוף לסיסמאות חלשות או חוזרות. בנוסף הוא מספק אימות רק עבור שירותים ולקוחות.
קישורים חיצוניים
- פרוטוקול קרברוס לאימות רשת תקשורת, באתר המכון הטכנולוגי של מסצ'וסטס
- https://www.educba.com/kerberos/
- קישורים נוספים
הערות שוליים
32018561קרברוס (פרוטוקול)