פרוטוקול קרברוס מסתמך על הצפנה סימטרית בלבד ודורש סיוע של צד שלישי נאמן. מהלכי הפרוטוקול מוגנים מפני ציתות והתקפת שידור חוזר. לעומת פרוטוקול סיסמה רגיל הנקרא "אימות חלש", פרוטוקול קרברוס מציע מה שמוגדר "אימות חזק", כיוון שהוא מערב הצפנה כדי להגן על מפתחות ההתקשרות מפני ציתות בזמן העברתם.
היסטוריה והתפתחות.
פרוטוקול קרברוס נולד כחלק מפרויקט אתנה (Athena Project), שמו ניתן לו על שם הדמות קרברוס מהמיתולוגיה היוונית, מפלצת דמוית כלב, בעלת שלושה ראשים ששירתה את האדס - "אל השאול", בשמירה על שער הגיהנום.
פרויקט אתנה הוקם על ידי MIT ב-1979 במטרה לספק הגנה על רשת המחשבים הפנימית של המכון. לאפשר גישה למחשבי המכון על ידי המשתמשים המורשים ולמנוע גישה לקבצים פרטיים ממי שלא הוסמך לכך. בשלבים הראשונים פותחו שלוש גרסאות פנימיות של הפרוטוקול שלא פורסמו. גרסה 4 שמפתחיה העיקריים היו סטיב מילר וקליפורד ניומן פורסמה במחצית השנייה של 1980 ונועדה בעיקר לצורך הפרויקט. לאור ליקויים שהתגלו בה, פותחה גרסה 5 של הפרוטוקול על ידי צוות של 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 של אפל על מחשבי מקינטוש, סולאריס ועוד.
יעדי הפרוטוקול.
קרברוס פותח במטרה לספק אימות מהימן בין משתמשים ברשת תקשורת פתוחה שבה אפשר לצותת לחילופי המסרים וליירטם. הצלחת הפרוטוקול תלויה באמינות המחשבים המשתתפים בתקשורת. שרתי האימות, ספקי השירותים והלקוחות חייבים להיות בטוחים ומעודכנים באופן כזה שלא יכילו פרצות כך שניתן יהיה להבטיח את תהליך האימות. במילים אחרות, פרוטוקול קרברוס הוא פרוטוקול אימות בין מחשבים אמינים ברשת לא אמינה. אם מישהו מצליח לפרוץ לאחד המחשבים המשתתפים בפרוטוקול אין כל תועלת בו, לכן הנחת היסוד של הפרוטוקול היא שכל המשתתפים "הגונים". יעדי הפרוטוקול הם:
מרכז הפצת מפתחות.
פרוטוקול קרברוס הוא גם פרוטוקול שיתוף מפתח המבוסס על פרוטוקול נידהאם-שרודר (Needham &amp; Schroeder) עם שיפורים שהוצעו על ידי Denning &amp; Sacco. הרעיון הוא להסתייע בשרת ייעודי המכונה KDC קיצור של Key Distribution Center שתפקידו לייצר מפתחות הצפנה זמניים לצורך הצפנת שיחות בין הלקוחות ושרתים או בין שרתים. פרוטוקול קרברוס מכיל גם הגדרה לשרת ניהול הנקרא KADM שתפקידו לנהל את רשימת המפתחות הסודיים ארוכי הטווח של כל המשתמשים, להוסיף או למחוק משתמש לפי הצורך.
KDC של קרברוס הוא שרת אימות המייצר תעודות אימות איתם הלקוחות יכולים לזהות עצמם ולקבל את השירות המבוקש. למרות ההתייחסות אליו כאל ישות אחת הוא למעשה מורכב משלושה חלקים (כמתואר בתרשים למעלה): מסד נתונים, שרת אימות (AS) ושרת הנפקת טיקטים (TGS). מעשית הפרוטוקול מיושם בדרך כלל במחשב אחד המכיל את כל הגופים.
מפתח שיחה.
המפתחות המשותפים לשרתים והלקוחות (מפתח סודי המשותף לשרת האימות והלקוח שנגזר מסיסמת הלקוח ומפתח אחר המשותף לשרת האימות ונותן השירות שנקבע על ידי מנהל הרשת) נקראים מפתחות ארוכי טווח כי הם קבועים ואינם משתנים לאחר שיחה אחת. היות שאין קשר בין המפתחות, הלקוח אינו יכול להתקשר עם נותן השירות ללא קיומו של מפתח משותף נוסף להצפנת התקשורת ביניהם לפחות למשך הזמן השיחה. מפתח זה המונפק על ידי ה-KDC כחלק מהטיקט נקרא מפתח שיחה. מפתח השיחה מונפק בשני עותקים, עותק אחד מיועד לנותן השירות והוא "נעטף" על ידי ה-KDC בתוך הטיקט באופן כזה שללקוח עצמו אין גישה אליו אלא רק נותן השירות המתאים שמחזיק במפתח ארוך טווח המשותף לו ולשרת האימות. העותק השני המיועד ללקוח עצמו והוא "נעטף" בנפרד בחבילה המוצפנת באמצעות המפתח הנגזר מסיסמת המשתמש. כך שלמשתמש היכולת לפענח את החבילה המיועדת אליו ולחלץ את המפתח השיחה מתוכה. למפתח שיחה תפקיד חשוב בסביבת קרברוס.
תעודת אימות.
קיומו של טיקט שירות תקף (בקיצור טיקט) עדיין אינו משליך בהכרח על אימות הלקוח. היות שמדובר ברשת פתוחה, כל אחד יכול ליירט טיקט ולנסות לעשות בו שימוש מאוחר יותר. קיומה של כתובת IP לא עוזרת במיוחד כיוון שכידוע קל לזייף כתובות. הדבר היחיד שהלקוח ונותן השירות יודעים ואף אחד אחר לא, הוא מפתח השיחה (כמובן בנוסף למנהל הרשת שהכין אותו, אבל הוא בהגדרה נקרא "נאמן"), לכן האסטרטגיה שנוקט פרוטוקול קרברוס היא: יחד עם הטיקט שהלקוח שולח לנותן השירות הוא מצרף תעודת אימות (authenticator) בה מופיעים פרטי הלקוח וחותם זמן כשהם מוצפנים באמצעות מפתח השיחה. נותן השירות מצידו פועל בדרך מאוד פשוטה, תחילה הוא מחלץ את המפתח השיחה מהטיקט המיועד אליו, איתו הוא משתמש כדי לפענח את תעודת האימות. אם הלקוח הוא באמת מי שהוא טוען שהוא, השרת יוכל לפענח את התעודה בהצלחה ולחלץ את פרטי הלקוח ולבדוק שאכן זמן הנפקת התעודה "טרי". תעודה שעבר זמנה כלומר שהזמן המופיע בה רחוק לפחות שתי דקות מהזמן בשעונו של השרת תדחה מיד. כאן רואים מדוע יש חשיבות לסינכרון הזמן בין השעונים של מחשבים השייכים לאותו תחום.
קיימת אפשרות קלושה שהמתקיף יצליח ליירט טיקט ותעודת אימות ולשלוח אותם בתוך פחות משתי דקות או כל חלון זמן אחר שהוגדר על ידי המערכת. הפתרון שנוסף בגרסה 5 הוא "מטמון שידור חוזר" (Replay cache). בעיקר בשרתים, נוספה אפשרות למעקב אחרי כל התעודות שהתקבלו במשך חלון הזמן שנקבע, והמערכת יודעת לדחות תעודות כפולות ובכך למנוע התקפת שידור חוזר מסוג זה. הבעיה תיפטר בתנאי שהמתקיף המתוחכם לא יצליח לשלוח את התעודה והטיקט הגנובים לפני שהלקוח עצמו הספיק לעשות זאת. זה כמובן יהיה משעשע כי הלקוח הלגיטימי עלול להיות מואשם ב"התחזות".
הרשאות.
היות שהלקוח לעולם אינו שומר את סיסמתו במחשב (או לפחות זו ההמלצה), כדי להתאים את המערכת למצב של "אימות יחיד" (בכניסה) הנקרא בקיצור SSO, יש צורך לשמור במקום זמני כלשהו את מפתח השיחה והתעודות לפחות עד שהשיחה מסתיימת. המקום בו מאוחסן המידע הזה נקרא מטמון הרשאות (Credential Cache). מיקום המטמון אינו תלוי בפרוטוקול והוא משתנה מיישום אחד לאחר לפי העדפה. במימוש של MIT לצורך תאימות מטמון ההרשאות נשמר במערכת הקבצים. להגברת הביטחון יש כאלו (כמו Active Directory של מיקרוסופט) שמאחסנים אותו בזיכרון הליבה המוגן מפני גישה ברמת משתמש ואינו מועתק למקום אחר בזמן שהמערכת מדפדפת.
טרמינולוגיה.
הערה: הסוגריים המסולסלים בתרשים ובתיאור הפרוטוקול להלן מייצגים את חלק המידע המוצפן כאשר מפתח ההצפנה מצוי מיד לאחריהם בליווי סוגריים המציינים את השותפים למפתח (הגורמים שהמפתח ידוע להם). יתר חלקי המידע מועברים באופן גלוי.
תיאור מהלכי הפרוטוקול.
1. המשתמש מקיש שם משתמש וסיסמה בצד הלקוח. הלקוח (המחשב) מבצע פונקציית גיבוב חד כיוונית על הסיסמה שהוקלדה והתוצאה המתקבלת מהווה מפתח סודי של הלקוח.
2. הלקוח שולח בשמו של המשתמש מסר קריא לשרת האימות (AS) לקבלת המלצה (credential) עבור שירות או גישה למשאב מסוים מספק השירות, בנוסח: "משתמש פלוני מבקש לקבל שירות מספק פלוני". שימו לב שהלקוח אינו נדרש לשלוח סיסמה או מפתח סודי כלשהו לשרת האימות.
3. שרת האימות מזהה את הלקוח ברשימותיו על פי טענת זהותו. אם הלקוח האמור אכן מופיע ברשימותיו, שרת האימות מחזיר לו המלצה המורכבת משני מסרים מוצפנים:
מהלך 1: שרת אימות ללקוח (המלצה)