1. הגנה במערכות מתוכנתות חורף תשס " ד הרצאה 4 ניהול מפתחות PKI

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

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

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

5. הגנה - חורף תשס"ד - הרצאה 45 ניהול מפתחות ( המשך ) עדכון מפתחות –במערכות מפתח ציבורי, יש לאמת את המפתח הציבורי –במערכות סימטריות, דרוש פרוטוקול הסכמה על מפתחות. Revocation –במערכות מפתח ציבורי, ליוצר המפתח בד”כ אין שליטה על מספר העותקים המופצים של המפתח הציבורי. דרוש ליצר “רשימה שחורה” של מפתחות.

6. הגנה - חורף תשס"ד - הרצאה 46 הסכמה על מפתחות שני הצדדים רוצים להסכים על מפתח סודי דרך ערוץ ציבורי. דרך אפשרית: הצפנת הסוד ע"י צופן מפתח פומבי (כמו RSA). נראה דרך נוספת: אלגוריתם להסכמה על מפתח – האלגוריתם של Diffie-Hellman.

7. הגנה - חורף תשס"ד - הרצאה 47 אלגוריתם Diffie-Hellman (DH) האלגוריתם מאפשר לשני אנשים להסכים על מפתח סודי דרך ערוץ ציבורי. לכל אחד מהצדדים יש מפתח פרטי ומפתח פומבי. כל אחד מהצדדים מחשב את הסוד המשותף על ידי שימוש במפתח הפרטי שלו, ובמפתח הציבורי של הצד השני.

8. הגנה - חורף תשס"ד - הרצאה 48 Diffie-Hellman (DH) יהי p מספר ראשוני ויהי g יוצר של * Z p, החבורה הכפלית של Z p. הפרמטרים g ו -p ידועים לכל משתמשי המערכת. המפתחות : המפתח הפומבי המפתח הפרטי g y (mod p)yאליס g x (mod p)xבוב

9. הגנה - חורף תשס"ד - הרצאה 49 אליסבוב 1) x,g x (mod p) y,g y (mod p) 2) g x (mod p) g y (mod p) 3) g yx (mod p)g xy (mod p)

10. הגנה - חורף תשס"ד - הרצאה 410 ניהול המפתחות הפומביים (רלוונטי גם ל-DH וגם לאלגוריתמי מפתח פומבי אחרים, כגון צפנים) כיצד תדע אליס מהו המפתח הפומבי של בוב? הדרך הטבעית: ברגע שהם רוצים לדבר, יחליפו את המפתחות הפומביים שלהם (למשל, כך זה נעשה בפרוטוקול DH לעיל). הבעיה: אז ניתן לבצע התקפת האיש שבאמצע (Man in the middle).

11. הגנה - חורף תשס"ד - הרצאה 411 Matt התקפת האיש שבאמצע Man in the middle attack AliceBob Hello, I am Alice g x Hello, I am Bob g y Matt Hello, I am Alice g x Hello, I am Alice g x’ Hello, I am Bob g y Hello, I am Bob g y’ E (M) g xy’ E (M) g x’y

12. הגנה - חורף תשס"ד - הרצאה 412 פתרון: שימוש בסרטיפיקטים במערכת ישנה רשות שכולם סומכים עליה: Certification Authority (CA) שתפקידה לחתום על סרטיפיקטים. כל המשתמשים במערכת יודעים את המפתח הפומבי של ה-CA ה-CA נותן לכל משתמש סרטיפיקט. הסרטיפיקט הוא מחרוזת שמכילה: שם המשתמש, המפתח הפומבי שלו ותאריך פג התוקף של הסרטיפיקט. כל זה חתום על ידי ה-CA

13. הגנה - חורף תשס"ד - הרצאה 413 אימון ב -CA המשתמשים ב-CA סומכים על כך שלפני הנפקת הסרטיפיקט הוא מוודא שהזהות שמופיעה בסרטיפיקט שייכת לבעלים של המפתח זוג המפתחות הפרטי/פומבי שחציו הפומבי מופיע בסרטיפיקט CA-ים נבדלים זה מזה ברמת תהליך הוידוא שהם מבצעים לפני ההנפקה

14. הגנה - חורף תשס"ד - הרצאה 414 סרטיפיקטים כאשר משתמש A שולח למשתמש B את המפתח הפומבי שלו, הוא מצרף אליו את סרטיפיקט התואם אם B סומך על ה-CA שהנפיק את הסרטיפיקט, הוא מאמת את החתימה של ה- CA על הסרטיפיקט וכך מוודא שהמפתח המפתח הפומבי אכן שייך ל-A

15. הגנה - חורף תשס"ד - הרצאה 415 בעיה אם A ו-B הם שני אנשים שלא נפגשו מעולם וחיים במקומות שונים ומרוחקים, אין שום סיבה להניח שקיים CA אחד ששניהם מכירים וסומכים עליו. אפילו אם CA אחד כזה היה קיים, העומס עליו היה גדול מאוד. פתרון: PKI (Public Key Infrastructure).

16. הגנה - חורף תשס"ד - הרצאה 416 PKI – מבוא

17. הגנה - חורף תשס"ד - הרצאה 417 מהו PKI PKI – תשתית להעברה, פרסום ואמות של מפתחות ציבוריים. המפתחות הפומביים בדרך כלל מפורסמים בעזרת סרטיפיקטים. הגדרה של PKI צריכה להכיל הגדרות של התהליכים הבאים: –מתן סרטיפיקט (certification): כולל מי מנפיק סרטיפיקט למי, תהלי ההנפקה, ואיפה הסרטיפיקט שמור. –אימות מפתח פומבי: כולל כיצד מוצאים סרטיפיקטים מתאימים, וכיצד מאמתים סרטיפיקט (האם הוא תקף). –ביטול הסרטיפיקט.

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

19. הגנה - חורף תשס"ד - הרצאה 419 סרטיפיקטים הגדרה של PKI בדרך כלל מכילה הגדרה של סרטיפיקט. סרטיפיקט – זהו הפורמט שבעזרתו מבהיר ה-CA שהמפתח הפומבי המצורף הוא אמין. למנפיק הסרטיפיקט קוראים CA (Certification Authority) סרטיפיקט מכיל שם המשתמש, המפתח הפומבי שלו ואולי עוד מידע על המשתמש, הכל חתום בעזרת המפתח הפרטי של ה-CA.

20. הגנה - חורף תשס"ד - הרצאה 420 דוגמא ל -PKI ה-PKI הפשוט ביותר הוא: CA יחיד, שמנפיק סרטיפיקטים לכל המשתמשים. כאשר אליס רוצה לקבל סרטיפיקט, היא ניגשת פיסית ל-CA, מזדהה בפניו ומקבלת סרטיפיקט. בהמשך, אם בוב ירצה לדעת מהו המפתח הפומבי של אליס, היא תשלח לו את הסרטיפיקט. הבעיה: כל המשתמשים צריכים לסמוך על CA אחד, ולגשת אליו פיסית. ברשתות גדולות זה לא מעשי.

21. הגנה - חורף תשס"ד - הרצאה 421 רוב PKI-ים מכילים מספר CA-ים. משתמשים יכולים לשמש כ-CA-ים. למשתמשים שלא משמשים כ-CA-ים קוראים EE (End Entity). CA יכול להנפיק סרטיפיקט ל-CA אחר או ל-EE. דוגמא: אליס מאמינה ל -CA1. בגלל ש -CA1 הנפיק סרטיפיקט ל -CA2, היא תאמין גם לסרטיפיקטים ש -CA2 הנפיק. CA1CA2 אליסבוב סימונים: CA EE X  Y: X חתם על הסרטיפיקט של Y

22. הגנה - חורף תשס"ד - הרצאה 422 מסלולי אמון בדוגמא לעיל, אליס בונה מסלול אמון (Trust Path): (CA1,CA2,Bob). באופן כללי, כאשר A רוצה לאמת את המפתח הפומבי של B, מסלול (CA 1,CA 2,…,CA n,,B) הוא מסלול אמון חוקי, אם: –CA 1 הוא CA ש-A סומך עליו ויודע את המפתח הפומבי שלו (למשל, קיבל אותו באופן פיסי). –כל ישות במסלול (פרט ל-B) חתמה על סרטיפיקט של הישות הבאה אחריה במסלול.

23. הגנה - חורף תשס"ד - הרצאה 423 ארגון ה -CA- ים הדרך שבה ה-CA-ים מאורגנים (כלומר: מי חותם למי, איך נראה מסלול אמון וכיצד מוצאים אותו) – זה חלק חשוב מהגדרה של PKI. לדוגמא: –מבנה היררכי כללי: ה-CA-ים מאורגנים בעץ. כל צומת פנימי בעץ חותם לילדיו ולאביו. העלים – EE’s –יתכנו חתימות נוספות ("קיצורי דרך" – cross certification).

24. הגנה - חורף תשס"ד - הרצאה 424 דוגמא Root Israel US UK IBM Elbit IntelIBM Moshe Israel US IBM Israel John

25. הגנה - חורף תשס"ד - הרצאה 425 ארגון CA- ים - המשך ישנם PKI-ים ללא מבנה מסודר של CA-ים. לדוגמא, ב-PGP אין מבנה בכלל. כל משתמש משמש גם כ-CA ויכול לחתום על סרטיפיקטים של משתמשים אחרים. כל משתמש מחליט לבד לאילו סרטיפיקטים להאמין. למבנה כזה קוראים web of trust. ישנם PKI-ים בעלי מבנים נוספים...

26. הגנה - חורף תשס"ד - הרצאה 426 Scalability נרצה ש-PKI שמיועד לרשתות גדולות יקיים את תכונת ה-scalability, כלומר: ישאר מעשי גם הם ישנם המון משתמשים. בפרט, מסלולי האמון יהיו קצרים יחסית וקלים למציאה ובדיקה. לדוגמא: Web of trust לא מעשי מבחינה זו. למרות שמעריכים שבין כל זוג משתמשים, אורך מסלול האימות יהיה קצר (6 או 7), לא כל מסלול אמון מתאים, מכיוון שכל משתמש מחליט לבד על מי הוא סומך.

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

28. הגנה - חורף תשס"ד - הרצאה 428 אמון PKI מגדיר מודל של אמון. דוגמאות למודלים: –לכל משתמש, קיים לפחות CA אחד שעליו המשתמש סומך לגמרי. אם CA זה סומך על CA’, אז גם המשתמש סומך על CA’ באופן אוטומטי. –(PGP): כל משתמש מגדיר באופן מפורש על מי הוא סומך. –סומכים על CA-ים מסוימים רק למטרות מסוימות: כמו למשל, מאמינים רק לסרטיפיקטים שמונפקים על ידי ה- CA, בהם זהות המשתמש היא כתובת הדואר האלקטרוני. סומכים על סרטיפיקטים על מפתחות חתימה אך לא מפתחות הצפנה.

29. הגנה - חורף תשס"ד - הרצאה 429 אימות סרטיפיקט אימות סרטיפיקט מורכב מ: –אימות החתימה. –בדיקה שהסרטיפיקט עדיין בתוקף (נהוג כי תוקף הסרטיפיקט רשום בתוך הסרטיפיקט, אך יש מקרים בהם צריך לפנות למנפיק הסרטיפיקט.( –בדיקה שהסרטיפיקט לא בוטל.

30. הגנה - חורף תשס"ד - הרצאה 430 ביטול סרטיפיקטים (revocation) מתי צריך לבטל סרטיפיקט? המפתח הפרטי (המתאים למפתח הפומבי שבסרטיפיקט) התגלה. המפתח הפרטי של ה-CA (שאתו חתום הסרטיפיקט) התגלה. ה-CA כבר לא מחזיק סרטיפיקטים עבור משתמש זה (למשל: המשתמש עבר לעבוד בחברה אחרת).

31. הגנה - חורף תשס"ד - הרצאה 431 CRL – certificate revocation list נהוג שכל CA מפרסם רשימה של סרטיפיקטים שבוטלו והיו חתומים ע"י ה-CA. לרשימה זו קוראים CRL. הרשימה חתומה ע"י ה-CA, ופרט לרשימת הסרטיפיקטים המבוטלים מכילה מספר סידורי, תאריך פרסום הרשימה והתאריך בו תפורסם הרשימה הבאה. יש לבדוק את המפתח של ה-CA אתו הרשימה חתומה.

32. הגנה - חורף תשס"ד - הרצאה 432 CRL - המשך לפעמים, יש צורך לפרסם CRL לפני התאריך המיועד של ה-CRL הבא. על המשתמשים להחליט לבד, כל כמה זמן הם בודקים את ה-CRL. ה-CRL נשלח למשתמש יחד עם ה-time stamp, חתום ע"י ה-CA, ומכיל את כל הסרטיפיקטים שבוטלו עד כה ותוקפם עדיין לא פג.

33. הגנה - חורף תשס"ד - הרצאה 433 CRL - המשך השימוש ב-CRL עושה את תהליך אימות של סרטיפיקט מסובך. בנוסף, גודל הרשימות יכול להיות מאוד גדול, מה שמגדיל עוד יותר את הזמן הדרוש לאימות סרטיפיקט. פתרון חלקי: חלוקה של CRL לכמה תת רשימות.

34. הגנה - חורף תשס"ד - הרצאה 434 Out of band authentication בדרך כלל, כאשר משתמש מצטרף ל-PKI, הוא צריך להיפגש פיסית עם ישויות קיימות ב-PKI (בד"כ CA-ים): צריך להזדהות בפני ה-CA על- מנת לקבל סרטיפיקט, ורצוי לקבל מפתח פומבי של CA אחד לפחות באופן פיסי. בד"כ רצוי שמודל של PKI יקטין ככל האפשר אותנטיקציה מסוג זה, אך אי אפשר להיפטר ממנה לגמרי.

35. הגנה - חורף תשס"ד - הרצאה 435 בעיות במימוש PKI Scalability –יש צורך במספר גדול של CAs מקושרים בינהם –שמות עמידות ואמינות –חשיפת מפתחות –ביטול certificates (revoke) בעיות משפטיות : אימון, אחריות פרטיות, אנונימיות

36. הגנה - חורף תשס"ד - הרצאה 436 PKI היום רוצים להגדיר ולהקים תשתית גלובאלית של PKI באינטרנט, כך שכל זוג אנשים בעולם יוכלו לדבר ביניהם בצורה בטוחה. היום עובדים על התאמה של X.509 לצורך זה (מודל זה נקרא PKIX).

37. הגנה - חורף תשס"ד - הרצאה 437 X.509

38. הגנה - חורף תשס"ד - הרצאה 438 X.509 סטנדרד של ITU-T שמגדיר PKI. זהו סטנדרד מאוד חשוב. הרבה פרוטוקולים (לדוגמא: IPSec, SSL) מסתמכים על סרטיפיקטים ופרוטוקולי אימות של X.509. מגדיר ביצוע אימות עבור סטנדרד של מדריך X.500. הגירסה הראשונה הופיעה ב-’88. היום יש כבר גירסה שלישית. ממליץ, אך לא מחייב לבצע אימות באמצעות RSA יחד עם פונקצית hash.

39. הגנה - חורף תשס"ד - הרצאה 439 X.500 סטנדרד של ITU-T שמתאר מדריך (Directory) מקוון, גלובאלי, מבוזר. מדריך – זה שרת או קבוצה מבוזרת של שרתים ששומרים מבנה נתונים עם מידע על משתמשים. ב-X.500 בכל כניסה במדריך שמורות תכונות שונות, אחת מהן היא ה-public key של הישות המתאימה. המדריך מתוחזק ומתופעל ע"י הירארכיה (עץ) של תתי מדריכים. לכל ישות בעץ יש שם שהוא ייחודי מבין אחיו. לכל ישות בעץ יש שם ייחודי בעולם Distinguished Name (DN) המתקבל ע"י שרשור השמות שבמסלול מן השורש אל הצומת המתאים בעץ.

40. הגנה - חורף תשס"ד - הרצאה 440 Distinguished Name (DN) שם שהוא יחודי במדריך הגלובאלי – בעל משמעות חוקית קבוצה סדורה של זוגות. כל זוג מכיל מילת מפתח שמורה, ומחרוזת שמכילה ערך. דוגמא ל-DN: CN (Common Name) = David Cohen OU (Organizational Unit) = Finance O (Organization) = IBM C (Country) = Israel

41. הגנה - חורף תשס"ד - הרצאה 441 X.509 לא מגדיר כיצד ה-CA-ים מאורגנים, אבל ממליץ לשמור על המבנה ההיררכי של X.500, כלומר: ה-CA-ים הם הצמתים הפנימיים של המדריך. כל CA חותם לבניו על סרטיפיקטים. ניתן גם להוסיף cross certification.

42. הגנה - חורף תשס"ד - הרצאה 442 X.509 v3 Certificate format Version Certificate serial number Signature algorithm Issuer DN Validity Period Subject DN CA’s siganture on the Certificate Subject public key information חתום

43. הגנה - חורף תשס"ד - הרצאה 443 קבלת סרטיפיקט X.509 מגדיר שתי דרכים לקבלת סרטיפיקט Central : בשיטה זו ה-CA מייצר את המפתח הפרטי והציבורי עבור ה-subject, ושולח אותם (בצורה מוגנת) אל ה-subject. שיטה זו מתאימה לחלוקה של certificates שמאוכסנים על אמצעי פיסי ממוגן (לדוגמא smart card) Distributed: בשיטה זו ה-subject מייצר את המפתח הפרטי והציבורי, ושולח בקשה אל ה-CA שמחזיר לו certificate עבור המפתח הציבורי

44. הגנה - חורף תשס"ד - הרצאה 444 CRL המספר הסידורי שמופיע בסרטיפיקט הוא יחודי מבין כל הסרטיפיקטים שהונפקו ע"י אותו CA. X.509 מגדיר מנגנון שבו CA מפרסם רשימה של סרטיפיקטים מבוטלים (CRL). הרשימה מכילה את המספרים הסידוריים של הסרטיפיקטים שבוטלו יחד עם התאריך בו הסרטיפיקט בוטל. בנוסף, CRL מכיל שדות שראינו קודם (תאריך, מספר סידורי וכו'). ה-CRL חתום ע"י ה-CA.

45. הגנה - חורף תשס"ד - הרצאה 445 PGP

46. הגנה - חורף תשס"ד - הרצאה 446 PGP - מבוא תוכנה שהומצאה על ידי Phil Zimmermann. מאפשרת הצפנה ואימות של קבצים והודעות דואר אלקטרוני. תוכנה יעילה ופשוטה. מאוד נפוצה היום.

47. הגנה - חורף תשס"ד - הרצאה 447 מודל האמון של PGP לא מניח קיום של רשות שכל המשתמשים סומכים עליה (CA). כל משתמש משמש כ-CA ויכול לחתום על סרטיפיקטים של משתמשים אחרים כרצונו. כל משתמש מחליט לבד בצורה מפורשת על מי הוא סומך ועל מי לא.

48. הגנה - חורף תשס"ד - הרצאה 448 מודל האמון של PGP המפתחות הפומביים נשלחים בין המשתמשים בעזרת הסרטיפיקטים. סרטיפיקט מכיל כתובת דואר אלקטרוני ומפתח פומבי. הסרטיפיקטים חתומים ע"י משתמשים שונים. למשל: אליס יכולה לבקש מהחברים שלה לחתום על הסרטיפיקט שלה. הרעיון: בוב יאסוף חתימות שונות על הסרטיפיקט של אליס. על סמך החתימות הוא יחליט האם הוא מאמין לסרטיפיקט או לא.

49. הגנה - חורף תשס"ד - הרצאה 449 מודל האמון של PGP - המשך כיצד Bob מחליט האם להאמין לסרטיפיקט של Alice או לא? אינטואיטיבית, Bob צריך להאמין רק לחתימות ש: –נעשו ע"י מפתח פרטי אמיתי של החותם. –נעשו ע"י משתמשים שהוא סומך עליהם.

50. הגנה - חורף תשס"ד - הרצאה 450 מחזיק המפתחות הפומביים כל משתמש ב -PGP מחזיק מבנה נתונים שנקרא " מחזיק המפתחות הפומביים " (Public Key Ring) ובו שמורים מפתחות פומביים של משתמשים שונים. מבנה נתונים זה הוא טבלה בה כל שורה מתאימה למפתח פומבי של משתמש כלשהו. Time Stamp KeyIDPublic Key User ID Owner Trust Key Legitimacy SignaturesSig. Trusts נתעלם משני השדות הראשונים.

51. הגנה - חורף תשס"ד - הרצאה 451 מימוש מודל האמון של PGP נניח שמדובר במחזיק מפתחות ששייך לבוב. נתבונן בשורה שמתאימה למפתח פומבי כלשהו של אליס. ארבע השדות האחרונים הם: Key Legitimacy – שדה בינארי אשר קובע האם בוב מאמין שזה באמת מפתח פומבי של אליס. ערך שדה זה מחושב ע"י PGP על סמך שדות אחרים. Signatures – בשדה זה בוב אוסף חתימות על הסרטיפיקט שנעשו ע"י משתמשים אחרים.

52. הגנה - חורף תשס"ד - הרצאה 452 מימוש של מודל האמון של PGP - המשך Owner Trust – שדה שנקבע על ידי בוב. השדה מייצג את האמון של בוב בחתימותיה של אליס על מפתחות פומביים של משתמשים אחרים. הערכים האפשריים של השדה הם: –Ultimate Trust – ערך זה יכול להינתן רק לשורות שמתאימות למפתחות של המשתמש עצמו (אליס). –Always Trust –Usually Trust –No Trust Signatures trusts – עבור כל חתימה שמופיעה בשדה signatures, נשמר את ערך ה-Owner trust של המפתח החותם.

53. הגנה - חורף תשס"ד - הרצאה 453 מימוש מודל האמון - הערות יש הבדל משמעותי בין השדות Key Legitimacy ו- Owner Trust. עבור כל רשומה במחזיק המפתחות, עשויים להיות מספר זוגות של Signature+Signature Trust.

54. הגנה - חורף תשס"ד - הרצאה 454 חישוב השדה Key Legitimacy לוקחים בחשבון רק חתימות שנעשו בעזרת מפתח שהוא לגיטימי בעיני בוב. כל חתימה עם ערך Signature trust שהוא Ultimate תקבל משקל 1. כל חתימה עם ערך Always Trusted תקבל משקל 1/X. כל חתימה עם ערך Usually Trusted תקבל משקל 1/Y. כל חתימה עם ערך Not Trusted תקבל משקל 0. X ו-Y הם פרמטרים שנקבעים ע"י המשתמש (בוב). אם לא נאמר אחרת, נניח כי X=1, Y=2.

55. הגנה - חורף תשס"ד - הרצאה 455 חישוב השדה Key Legitimacy - המשך אם סכום המשקלות של כל החתימות שבשדה Signatures הוא  1, ערך השדה Key Legitimacy נקבע להיות 1. אחרת, ערך השדה הוא 0. על-מנת שערך השדה יהיה 1, צריך חתימה של משתמש אחד עם Ultimate Trust, או X משתמשים שהם Always Trusted, או Y משתמשים שהם Usually Trusted (או קומבינציה אחרת עם סכום משקלות 1 לפחות).

56. הגנה - חורף תשס"ד - הרצאה 456 מחזיק המפתחות של אליס KeyOwner Trust SigsSig Trusts Key Legit K B (Bob)AlwaysK E (Eve) K D (David) K J (John) K E (Eve)UsuallyV K D (David)Always- K J (John)AlwaysV Alw. (V) Alw. (-) Us. (V) 1/2 - 1 V

57. הגנה - חורף תשס"ד - הרצאה 457 D Alice B C IHG E F דוגמא לחישוב Key Legitimacy במחזיק המפתחות של אליס V V V VV

58. הגנה - חורף תשס"ד - הרצאה 458 מקרא Ultimate Trust W signed U The key is legitimate Always Trust Usually Trust No Trust V WU הנחה: X=1, Y=2