קרברוס (פרוטוקול)

מתוך ויקיפדיה, האנציקלופדיה החופשית
קפיצה אל: ניווט, חיפוש

קרברוס (Kerberos) הוא פרוטוקול אימות, המאפשר ליישומי תקשורת מבוססי שרת/לקוח לאמת זהויות באופן בטוח וכן לנהל התקשרות בטוחה באמצעות מפתחות הצפנה סודיים, מעל גבי רשת האינטרנט. הפרוטוקול הינו חלק מחבילת תוכנה חופשית שפותחה על ידי המכון הטכנולוגי של מסצ'וסטס (MIT) המשתמשת בפרימטיבים קריפטוגרפיים שונים ומיישמת בין היתר את הפרוטוקול בעיקר כמודל שרת-לקוח. הפרוטוקול מאפשר גם אימות זהויות הדדי, בו הלקוח והשרת יכולים לאמת זה את זהותו של זה. פרוטוקול קרברוס מסתמך על הצפנה סימטרית בלבד ודורש סיוע של צד שלישי נאמן. מהלכי הפרוטוקול מוגנים מפני ציתות והתקפת Replay attack. לעומת פרוטוקול סיסמה רגיל הנקרא "אימות חלש", פרוטוקול קרברוס מציע מה שמוגדר "אימות חזק", כיוון שהוא מערב הצפנה כדי להגן על מפתחות ההתקשרות מפני ציתות בזמן העברתם.

היסטוריה והתפתחות[עריכת קוד מקור | עריכה]

פרוטוקול קרברוס נולד כחלק מפרויקט אתנה (Athena Project), שמו ניתן לו על שם הדמות קרברוס מהמיתולוגיה היוונית, מפלצת דמוית כלב, בעלת שלושה ראשים ששירתה את האדס - "אל השאול", בשמירה על שער הגיהנום. פירוש המילה ביוונית "שד מהתהום".

פרויקט אתנה הוקם על ידי MIT ב-1979 במטרה לספק הגנה על רשת המחשבים הפנימית של המכון. לאפשר גישה למחשבי המכון על ידי המשתמשים המורשים ולמנוע גישה לקבצים פרטיים ממי שלא הוסמך לכך. בשלבים הראשונים פותחו שלוש גרסאות פנימיות של הפרוטוקול שלא פורסמו. גרסה 4 שמפתחיה העיקריים היו סטיב מילר וקליפורד ניומן פורסמה במחצית השנייה של 1980 ונועדה בעיקר לצורך הפרויקט. לאור ליקויים שהתגלו בה, פותחה גרסה 5 של הפרוטוקול‏[1] על ידי צוות של MIT בראשות קילפורד ניומן וג'ון קול ופורסמה בספטמבר 1993. גרסה זו הורחבה מספר פעמים במטרה לתקן מספר ליקויי בטיחות שהתגלו לאורך השנים בגרסה המקורית. MIT שחררה את גרסה 5 של הפרוטוקול לשימוש חופשי ופרסמה מימוש שלו לחלונות ולמקינטוש, תחת היתר שימוש הדומה למערכת ההפעלה BSD וכן פרסמה את ממשק תכנות יישומים (API) עבור קרברוס הנקרא GSS-API, המאפשר קריאות לפונקציות קריפטוגרפיות לצורך הפרוטוקול.

בשל העובדה שמימוש הפרוטוקול כולל אלגוריתם הצפנה כמו DES, שלטונות ארצות הברית הגדירו את הפרוטוקול כתחמושת ויצואו מתחומי ארצות הברית הוגבל תחת תקנות היצוא הנהוגים בסוגי תחמושת לפי חוקי ארצות הברית. לפני שינוי תקנות הייצוא הקריפטוגרפיות של ממשלת ארצות הברית, פותחה בשבדיה גרסה חופשית של פרוטוקול קרברוס הנקראת Heimdal על בסיס גרסה מוגבלת של MIT (שממנו הוסרו האלמנטים הקשורים בהצפנה). וכן פותחה גרסה נוספת של הפרוטוקול בשם Shishi תחת רישיון שימוש GPL של GNU.

החל מחלונות 2000 ומעלה, אימצה מיקרוסופט את פרוטוקול קרברוס כברירת המחדל לביצוע תהליכי אימות זהויות. חברת מיקרוסופט אינה משתמשת במימוש של MIT אלא תחת זאת בגרסה שונה במעט שהם פיתחו שנקראת SSPI, הצופן הסימטרי המשמש את הפרוטוקול הוא 128-RC4 בשילוב עם פונקציית גיבוב SHA-1. גם חברת אפל מיישמת את הפרוטוקול במחשבי מקינטוש במערכות ההפעלה Mac OS X.

תיאור הפרוטוקול[עריכת קוד מקור | עריכה]

פרוטוקול קרברוס מבוסס על פרוטוקול נידהם שרודר (Needham & Schroeder) עם שיפורים שהוצעו על ידי Denning & Sacco. בו נעזרים בצד שלישי מהימן, המכונה KDC קיצור של Key Distribution Center, שלמעשה מורכב משני גופים נפרדים Authentication Server בקיצור שרת AS לצורך אימות מקוון ו-Ticket Granting Server בקיצור TGS האחראי על הנפקת תעודות (ticket) התחברות. תפקידו של שרת קרברוס הוא לנהל מסד נתונים המכיל מפתחות הצפנה סודיים נפרדים עבור כל משתמש בין אם שרת או לקוח. לצורך התקשרות בין שני משתמשים או בין שרת ללקוח, מייצר ה-KDC מפתח שיחה חד פעמי ודואג להעבירו אל המשתמשים כשהוא מוצפן. עם מפתח-השיחה יכולים המשתמשים לאמת את זהותם ולנהל דו-שיח באופן בטוח. למרות שגופים אילו מתוארים כישויות נפרדות, הם יכולים להיות בשרת אחד. מעשית הפרוטוקול מיושם בדרך כלל בשרת KDC אחד המכיל את שני הגופים. הפרוטוקול משתמש באמצעים קריפטוגרפיים הן כדי להצפין את המסרים והן כדי להבטיח את שלמותם. להצפנה משתמשים באלגוריתם סימטרי כלשהו כמו DES או AES ולהבטחת שלמות המסרים משתמשים באלגוריתם סכום ביקורת או פונקציית גיבוב בטוחה. פרוטוקול קרברוס מכיל גם הגדרה לשרת ניהול הנקרא KADM שתפקידו לנהל את רשימת המפתחות של כל המשתמשים, להוסיף או למחוק משתמש לפי הצורך.

טרמינולוגיה:[עריכת קוד מקור | עריכה]

Service 
שירות; משאב רשת כגון חשבון משתמש, שירות הדפסה, שרות קבצים או חשבון דואר אלקטרוני.
User 
משתמש; בדרך כלל משתמש אנושי המעוניין בקבלת השירות או בגישה למשאב מרוחק.
Client
לקוח; מחשב המייצג את המשתמש. בעת הניסיון לגשת אל המשאב המרוחק המחשב דורש מהמשתמש להקליד את שמו וסיסמתו. לקוח יכול להיות גם גורם לא אנושי כגון שרת המבקש להתחבר לשרת אחר ומכונה Daemon.
Service Server
שרת השירות; שרת המספק שירותים כגון אילו המנויים לעיל, אליו הלקוח מנסה להתחבר על מנת לקבל את השירות המבוקש.
Ticket
תעודה; חבילת מידע המשודרת ברשת, הכוללת נתונים (חלקם מוצפנים) המאפשרים לשרת השירות לאמת את זהות הלקוח ולאפשר לו גישה לשירות או המשאב המבוקש.
Ticket Granting Server
שרת להנפקת תעודות (TGS); שרת קרברוס ייעודי המנפיק תעודות ללקוחות שברצונם להתחבר לשרת השירות האמור.
Authentication Server
שרת אימות (AS); שרת קרברוס ייעודי שתפקידו לקשר בין הלקוחות לבין שרת הנפקת התעודות (TGS). שרת זה מחזיק במסד נתונים מוצפן של לקוחות והסיסמאות השייכות להם.
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 וכן מפתח שיחה חדש (אם יש צורך), מוצפנים באמצעות מפתח השיחה המשותף. הלקוח מפענח את מסר האחרון ומודא שחותם הזמן מתאים לחותם הזמן שהוא שלח. אם כן הלקוח יכול לסמוך על השרת ויכול להשתמש בשירות המבוקש.

סיכום מהלכי הפרוטוקול: הלקוח מקבל משרת האימות המלצה איתה הוא מוכיח לשרת הנפקת התעודות שהוא מוסמך לקבלת תעודת השירות המבוקשת ומקבל אותה, באמצעותה הוא מוכיח לאחר מכן לספק השירות שזהותו אומתה וכי הוא רשאי לקבל את השירות המבוקש ומקבל אותו.

בטיחות ויעילות[עריכת קוד מקור | עריכה]

אלגוריתם הצפנה[עריכת קוד מקור | עריכה]

פרוטוקול קרברוס משתמש כבסיס בפונקציית הצפנה סימטרית מוסכמת ובטוחה להצפנת מסרי הפרוטוקול המתוארים. על כן בטיחותו נשענת בין היתר גם על בטיחות אלגוריתם ההצפנה שבשימוש. במפרט הבסיסי המפתחים ציינו את DES כאלגוריתם הצפנה אפשרי להצפנת מסרי הפרוטוקול. אולם קיימת הפרדה בין מהלכי הפרוטוקול לבין אמצעי ההצפנה. כך שכל אלגוריתם סימטרי, יכול לשמש לצורך ביצוע הפרוטוקול ובלבד שיכיל מנגנון הבטחת שלמות כלשהו.

בשל ליקויים שהתגלו בגרסה 5 של מימוש הפרוטוקול, המפתחים פרסמו ומפרסמים מדי פעם טיוטות נוספות המכילות שיפורים, תיקוני שגיאות והרחבות של הפרוטוקול שנועדו להתמודד עם ליקויים אילו. בסוף 2005 פורסמה טיוטה‏[2]RFC 4120 על ידי המפתחים ובה מספר עדכונים והרחבות של הפרוטוקול, ביניהם האפשרות של שימוש באתגר/מענה במקום חותם זמן. נוספו שדות אופציונליים במזהה ובתעודה על מנת לאפשר תוספות והרחבות וכן אומץ אלגוריתם AES כאלגוריתם המועדף להצפנת מהלכי הפרוטוקול ומפרט חדש לסכום ביקורת להבטחת השלמות. הרחבות נוספות של פרוטוקול קרברוס מאפשרות גם שילוב של הצפנה אסימטרית בשלבים הראשונים של הפרוטוקול.

ניהול מפתחות[עריכת קוד מקור | עריכה]

פרוטוקול קרברוס מחייב את הלקוח והשרת במהלך הפרוטוקול להחזיק במפתח הצפנה ומפתח שיחה לפיענוח מסרי הפרוטוקול במצב קריא (לא מוצפן). עובדה זו יוצרת נקודת תורפה מסוימת, אם תוקף פונטציאלי מצליח לחדור למערכת ולחלץ את המפתחות הללו, הוא יוכל להתחזות ללקוח ללא כל בעיה. בנוסף שרתי KDC אמורים לנהל מסד נתונים המכיל מידע על זהות המשתמשים והמפתחות הסודיים שלהם (הסיסמאות). מידע זה חייב להיות מוגן באמצעים קריפטוגרפיים. כמו כן התכנון הראשוני של הפרוטוקול מחייב את שרתי קרברוס לאחסן בקשות אחרונות על מנת למנוע התקפות שימוש חוזר. מימוש זה בעייתי בפלטפורמות מסוימות. השימוש באתגר/מענה מבטל את הצורך הזה.

אם לתוקף פוטנציאלי יש גישה לערוץ התקשורת בו מתנהל הדו-שיח בין השרת ללקוח, הוא יכול לאסוף מספר גדול של תעודות מוצפנות שנשלחו. בגרסה הבסיסית של הפרוטוקול לא הוגדרה שיטה מעשית להצפנת תהליך האימות. בשיטה הרגילה התעודות מוצפנות באמצעות המפתח הסודי של המשתמש שנגזר מהסיסמה שלו באמצעות פונקציה ציבורית מוסכמת. על כן התוקף יכול לנסות לפענח את התעודות באופן לא מקוון על ידי ניסיון לנחש את הסיסמה ולבדוק האם מפתח ההצפנה מתאים. לכן השימוש בפרוטוקול זה אינו פותר את המשתמשים מהצורך להחזיק בסיסמאות חזקות כלומר קשות לניחוש (ראו סיסמה).

התקפת שימוש חוזר - Replay attack[עריכת קוד מקור | עריכה]

כדי למנוע התקפת שימוש חוזר, שבה התוקף מנסה להתחזות ללקוח הלגיטימי על ידי שידור חוזר של מסרי הפרוטוקול מתהליך ישן. פרוטוקול קרברוס עושה שימוש במזהה המכיל חותם-זמן. חותם הזמן מאפשר לאכוף טריות ובכך לסכל ניסיון שימוש בבקשות ישנות. על כן סינכרון הזמן בין השרת והלקוח, הנו תנאי הכרחי בפרוטוקול קרברוס. מקובל לאפשר סטיה קלה (בדרך כלל כ-5 דקות), בין הזמן שמקורו בשעון הלקוח לבין הזמן בשעונו של השרת, בזמן קבלת הבקשה. בכל מקרה שהפרש הזמן עולה על שיעור סטייה שנקבע מראש, הבקשה נדחית.

שירות זמן מאובטח[עריכת קוד מקור | עריכה]

הצורך בסינכרון הזמן בגרסה הבסיסית, מטיל מגבלה על מימוש הפרוטוקול ומהווה חסרון משמעותי. אם הזמן בשעון השרת מוטעה ניתן יהיה לעשות שימוש במזהה ישן ובכך להתחזות ללקוח לגיטימי ללא בעיה. על כן יש צורך להגן על שעון השרת מפני שינויים חיצוניים על ידי תוקף פוטנציאלי. מלבד זאת כיוון שבטיחות הפרוטוקול תלויה בזמן, תהליך הסנכרון עצמו חייב להיות בטוח. אולם סנכרון שעון בטוח הינו בעיה קריפטוגרפית כשלעצמה. קיימת גרסה שונה של הפרוטוקול ללא שימוש בחותם זמן במחיר של מהלך נוסף.

צד שלישי[עריכת קוד מקור | עריכה]

התלות בצד שלישי מקוון מגביל את השימוש בפרוטוקול ומחייב כי שרת הצד השלישי יהיה זמין בעת הרצת הפרוטוקול. אם שרת קרברוס קורס, גורם הדבר להשבתה של כל מערכת האימות. כדי למנוע מצב כזה, בדרך כלל מערכת אימות כוללת מספר שרתי אימות של קרברוס.


קישורים חיצוניים[עריכת קוד מקור | עריכה]

הערות שוליים[עריכת קוד מקור | עריכה]