פרוטוקול שיתוף מפתח

בקריפטוגרפיה, פרוטוקול שיתוף מפתח (באנגלית: key exchange protocol) או יסוד מפתח (באנגלית key establishment) הוא פרוטוקול קריפטוגרפי שנועד להכנה ושיתוף של מפתחות הצפנה סודיים בין שתי ישויות או יותר ברשת תקשורת פתוחה הנגישה לציתות. בדרך כלל לאחר סיום הפרוטוקול המשתתפים משתמשים במפתח שהשיגו על מנת להצפין מסרים כלשהם שהם מעוניינים להעביר אחד לשני, לרוב בהצפנה סימטרית.

בעיית הפצת מפתחות

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

ערך מורחב – בעיית הפצת מפתחות

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

אפילו ברמה ארגונית, אם כל החברים בארגון יאלצו לשמור מפתחות סודיים בנפרד כדי שיוכלו להתקשר עם כל אחד מחברי הארגון בדיסקרטיות, מספר המפתחות הכולל שיזדקקו לו יגדל באופן מעריכי עם כמות החברים בארגון. עבור $n$ חברים נדרשים בסך הכול $\textstyle {\binom {n}{2}}=n^{2}$ מפתחות וכל חבר נדרש להחזיק בלא פחות מ-$n-1$ מפתחות סודיים. שלא להזכיר מפתחות נוספים שהוא צריך לשמור במקרה שהוא מתקשר עם גורמים מחוץ לארגון כמו שרתים, מסדי נתונים וכדומה. במקרה של ארגון גדול ניהול המפתחות הופך לנטל של ממש, ככל שקיימים יותר מפתחות כך קשה יותר לאחסן אותם בצורה בטוחה, במיוחד לאור העובדה שכל סביבה ממוחשבת המקושרת לרשת האינטרנט נתונה מעצם טבעה באופן מתמיד לאיומים חיצוניים מצד גורמים עוינים או מצד מתחרים.

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

KDC

פתרון חלקי הוא להשתמש ב"צד שלישי" נאמן בתור מתווך. המתווך יכול לשתף מפתח סודי עם כל חבר המצטרף לארגון או לרשת והוא אחראי לספק מפתחות שיחה סודיים לכל זוג מתקשרים אפשרי לפי דרישה. בשיטה זו החברים בארגון נדרשים לזכור רק מפתח סודי אחד. לפני כל התקשרות המתקשרים פונים תחילה לצד השלישי בסודיות באמצעות מפתחות ההצפנה שהם משתפים עמו כל אחד בנפרד כדי לקבל ממנו מפתח שיחה זמני מוצפן המתאים להתקשרות אחת. פתרון זה מלבד היותו מסורבל אינו מלא, כי הנחת היסוד היא שאפשר לסמוך על הצד השלישי (הנחה שלא תמיד נכונה) מלבד זאת ההנחה היא שלחברים ברשת או הארגון קיימת דרך פרטית בטוחה להתקשר עם הצד השלישי לפחות פעם אחת על מנת לשתף עמו מפתחות סודיים (למשל במפגש אישי אם מנהל הרשת עם קבלתם לעבודה או עם הרשמם). גוף כזה נקרא "מרכז הפצת מפתחות" (key distribution center) בקיצור KDC והוא פתרון מקובל מעשית חרף הקשיים המתוארים. לדוגמה מערכת ההפעלה חלונות של מיקרוסופט ומערכת ההפעלה OS X של אפל כוללים במנגנון האימות שלהם בין היתר את פרוטוקול קרברוס שמבוסס על פרוטוקול נידהם-שרודר שבעיקרון עושה שימוש בשרת הפצת מפתחות ייעודי. לשרת הפצת מפתחות מספר חסרונות מהותיים:

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

פרוטוקול דיפי-הלמן

ערך מורחב – פרוטוקול דיפי-הלמן

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

מאפיינים כלליים

מאז המצאת המפתח הציבורי ופתרון בעיית הפצת המפתחות פותחו מספר פרוטוקולים קריפטוגרפיים להעברת מפתח סודי המבוססים על הצפנה אסימטרית. באופן כללי קיימים שני סוגים של שיתוף או הקמה (Key establishment) של מפתחות הצפנה; תהליך "שיתוף מפתח" (Key agreement) שבו שני משתתפים או יותר מסכמים ביניהם על מפתח סודי כך שכל אחד מהם תורם את חלקו להקמתו במידה שווה, לעומת "העברת מפתח" (Key transport) שבו צד אחד מייצר ומעביר מפתח סודי למשתתפים האחרים, בעוד שהם אינם בהכרח תורמים להקמתו ואין להם שליטה עליו.

באופן כללי קיימים שני סוגי פרוטוקולים;

• שיתוף מפתח (Key agreement); שני משתתפים או יותר מסכימים ביניהם על מפתח סודי כך שכל אחד מהם תורם את חלקו להקמתו במידה שווה.
• העברת מפתח (Key transport); צד אחד מייצר ומעביר מפתח סודי למשתתפים האחרים, בעוד שהם אינם בהכרח תורמים להקמתו ואין להם שליטה עליו.

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

• אימות חד צדדי, שבו צד אחד משתף ומאמת מפתח עם צד אחר, כך שהוא מקבל אישור לזהותו של המשתתף האחר. נקרא Authenticated Key בקיצור AK.
• אימות דו צדדי, בפרוטוקול שבו תהליך האימות מספק אישור זהותם של כל הצדדים המשתתפים בפרוטוקול כלפי האחרים. נקרא: Authenticated Key agreement with Confirmation בקיצור AKC.

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

ביתר פירוט פרוטוקול שיתוף מפתח אמור לתת מענה לאיומים הבאים:

• מפתח ידוע (known-key); הפרוטוקול ייוותר בטוח נוכח מצב שבו נחשפו לעיני התוקף מפתחות שיחה ישנים (שנוצרו בעבר על ידי הפרוטוקול).
• שמירת סודיות קדימה (forward secrecy) או סודיות מושלמת קדימה; גם אם מפתח אימות ארוך-טווח של אחד המשתתפים נחשף, הדבר לא ישפיע על סודיות מפתחות שיחה שנוצרו בעבר לפני החשיפה.
• מניעת התחזות (impersonation); במצב שבו המפתח הפרטי של אחד המשתתפים ידוע לתוקף לא יתאפשר לו לעשות בו שימוש כדי להתחזות לאחרים כלפי משתמש זה (ברור שבמקרה כזה התוקף מסוגל להתחזות למשתמש הלגיטימי הזה כלפי אחרים כיוון שהמפתח הפרטי מייצג בעצם את זהותו, אך ההפך אינו מחויב המציאות ואף רצוי למנוע).
• שיתוף לא ידוע (unkown key-share); התוקף לא יצליח לגרום למשתתף אחד לשתף איתו מפתח סודי בעוד שהלה סבור בטעות ששיתף מפתח עם מישהו אחר (כלומר צד אחד מאמין נכון שהוא משתף מפתח עם מישהו שהוא מכיר בעוד שהצד השני למעשה משתף בלא ידיעתו מפתח עם התוקף וסבור שהוא מישהו אחר).
• שליטה; אף אחד מהצדדים לא יוכל לאלץ את מפתח השיחה שיהיה ערך כלשהו לפי בחירתו (כמו ערך המכיל חולשות נסתרות).

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

הגדרות ביטחון פורמליות

בניגוד להצפנה פרוטוקול שיתוף מפתח בדרך כלל אינטראקטיבי מטבעו. המשתתפים בפרוטוקול אליס ובוב מחליפים ביניהם מספר מסרים לפי פירוט מהלכי הפרוטוקול, בסופם הם אמורים לשתף ביניהם מפתח הצפנה סודי. נניח שהפרוטוקול מסומן באות $\Pi$ (המייצג אוסף של הוראות עבור אליס ובוב). וכן קיים פרמטר ביטחון $n$ שמתייחס בדרך כלל למספר הסיביות של המודלוס, היות שהפרוטוקול מוגדר בטוח מבחינה חישובית בלבד, פרמטר הביטחון קובע את כמות העבודה הנדרשת כדי לשבור את הפרוטוקול בכוח גס. בפרוטוקול מודרני בדרך כלל נוסף אלמנט של אקראיות. כל צד מפעיל אלגוריתם נפרד ובלתי תלוי כגון הטלת מטבע. בסיום הפרוטוקול אליס ובוב מקבלים את $k_{A}$ ו-$k_{B}$ באורך $n$ סיביות כל אחד, בהתאמה. כאשר השאיפה היא ש-$k_{A}=k_{B}$ כי אז המשמעות היא שהפרוטוקול הסתיים בהצלחה.

באופן אינטואיטיבי פרוטוקול שיתוף מפתח ייקרא בטוח אם המפתח ($k=k_{A}=k_{B}$) אינו ידוע לאיש מלבד המשתתפים בפרוטוקול. כל יריב המצותת לערוץ התקשורת ורואה את חילופי המסרים בין אליס ובוב לא יוכל להסיק כל מידע מועיל לגבי $k$ או בהגדרה חזקה יותר היריב ${\mathcal {A}}$ המאזין לרשת לא יוכל להבחין בין המפתח $k$ הנוצר על ידי הפעלת $\Pi$ לבין מחרוזת אקראית לגמרי באורך $n$ סיביות. בניסוח פורמלי ביטחון הפרוטוקול מתואר באמצעות הניסוי הבא:

ניסוי שיתוף מפתח ${\text{KE}}_{{\mathcal {A}},\Pi }^{\text{eav}}(n)$:

1. אליס ובוב קובעים את $1^{n}$, מריצים את הפרוטוקול $\Pi$ ומייצרים "תעתיק" ${\text{trans}}$ המכיל את המסרים שנשלחו על ידם ומפתח $k$ שמתקבל אצל כל אחד מהם.
2. מטילים מטבע: $b\leftarrow \{0,1\}$. אם $b=0$ בוחרים ${\hat {k}}\leftarrow \{0,1\}^{n}$ בהתפלגות אחידה ואילו אם $b=1$ מציבים ${\hat {k}}=k$.
3. ${\mathcal {A}}$ מקבל את ${\text{trans}}$ ואת ${\hat {k}}$ ומחזיר סיבית אחת $b'$.
4. תוצאת הניסוי מוגדרת הצלחה (1) אם $b'=b$ אחרת היא מוגדרת כישלון (0) במילים אחרות אומרים שאם ${\text{KE}}_{{\mathcal {A}},\Pi }^{\text{eav}}(n)=1$ אזי המתקיף ${\mathcal {A}}$ הצליח לשבור את הפרוטוקול והוא ייחשב לא בטוח לשימוש.

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

בהינתן פרוטוקול שיתוף מפתח $\Pi$ הוא ייקרא בטוח בנוכחות מצותת פסיבי רק באם עבור כל מתקיף פולינומי הסתברותי ${\mathcal {A}}$ קיימת פונקציית זניחות ${\text{negl}}$ כך שמתקיים:

$\Pr[{\text{KE}}_{{\mathcal {A}},\Pi }^{\text{eav}}(n)=1]\leq {\frac {1}{2}}+{\text{negl}}(n)$.

אם המתקיף מסוגל לזהות שמחרוזת כלשהי היא תוצאה של הפרוטוקול ולא מחרוזת סתמית בהסתברות גבוהה מחצי באופן משמעותי הרי שהוא הצליח לשבור את הפרוטוקול. הרעיון הוא ש-$k$ צריך "להראות" כמפתח אקראי טרי. הוא נקרא בשל כך "מפתח ארעי" (ephemeral key) כדי להבדילו מהמפתחות הסודיים ארוכי הטווח השייכים למשתתפים בפרוטוקול. המטרה של פרוטוקול שיתוף מפתח היא כמעט תמיד לייצר מפתח שיחה כדי להצפין מספר מוגבל של מסרים כלשהם תוך שימוש בפרימיטיב קריפטוגרפי כמו צופן AES או כדי לאמת מסרים כלשהם על ידי קוד אימות מסרים מוסכם על שני הצדדים.

מטעמי ביטחון מומלץ לא להשתמש ב-$k$ ישירות אלא לגזור ממנו מפתח אחר באמצעות פונקציית גזירת מפתח (Key derivation function) בקיצור KDF. למשל אפשר להזין את המפתח כקלט לפונקציית גיבוב קריפטוגרפית ולהשתמש בחלק מהפלט כמפתח שיחה.

אימות ושלמות

ערך מורחב – אימות מסרים

החסרון בפרוטוקול דיפי הלמן במתכונתו המקורית שהוא אינו מספק אימות זהויות ולכן חשוף להתקפת אדם באמצע, ללא אמצעי נוסף המשתתפים אינם יכולים להיות בטוחים עם מי הם מתקשרים. אפשר להוסיף מרכיב אימות על ידי חתימה דיגיטלית או תעודת מפתח ציבורי החתומה על ידי רשות מאשרת. משיקולי יעילות נעשו מאמצים לפתח פרוטוקולים המספקים אימות עקיף כחלק אינטרגלי ללא צורך בתהליכים נפרדים ובהתערבות צד שלישי, כמו MQV. אפשר לחלק את מרכיב האימות לשני סוגים, שיתוף מפתח מאומת שבו צד אחד משתף ומאמת מפתח עם צד אחר, כך שהוא מקבל אישור לזהותו של המשתתף האחר (כיוון אחד) ונקרא בקיצור AK וכן "שיתוף מפתח מאומת עם אישור", שבנוסף מאשר את זהות השרת כלפי הלקוח (דו כיווני) שנקרא בקיצור AKC (קיצור של Authenticated Key agreement with Confirmation).

פרוטוקולים

קיימים מספר פרוטוקולים לשיתוף מפתח, חלקם מכילים בנוסף מספר תכונות חשובות כמו: סודיות מושלמת קדימה (perfect forward secrecy) ויכולת הכחשה (deniability). ביניהם ניתן למנות את:

• SSL שמכיל מנגנון שיתוף מפתח המבוסס על פרוטוקול דיפי-הלמן.
• ISAKMP פרוטוקול ניהול מפתחות המספק תשתית לאימות והחלפת מפתחות. טיוטה RFC 2408.
• SIGMA המגיע במספר גרסאות ונכלל ב-IKE (תקן לשיתוף מפתח של האינטרנט).
• SKEME (מנגנון שיתוף מפתח בטוח) המכיל ארבעה מצבים שונים ביניהם שיתוף מפתח המבוסס על מפתח ציבורי.
• MQV
• SKIP, פרוטוקול ניהול מפתח פשוט הדומה ל-SSL.
• KEA (אלגוריתם שיתוף מפתח הנכלל בתשתית מפתח ציבורי X.509), טיוטה RFC 2528.
• AH (כותר אימות) בטיוטה RFC 4835, מספק אימות ללא קישוריות ונכלל בפרוטוקול IPSec.
• ESP (עטיפת חבילת אבטחה) בטיוטה RFC 4835 ונכלל בפרוטוקול IPSec.
• OTR פרוטוקול אבטחת מסרים מידיים להשגת פרטיות, אימות ויכולת הכחשה. ניתן להפעלה כתוסף מעל גבי פרוטוקולים אחרים כמו Pidgin.
• פרוטוקול סיגנל המיישם שיתוף מפתח אסינכרוני בין שני משתתפים כאשר אחד מהם אינו במצב מקוון.

ראו גם

• אימות זהות
• אימות מסרים
• פרוטוקול קרברוס
• פרוטוקול דיפי-הלמן
• MQV

הערות שוליים

הערך באדיבות ויקיפדיה העברית, קרדיט,
רשימת התורמים
רישיון cc-by-sa 3.0