מיסור שלא לפרסום

מתוך המכלול, האנציקלופדיה היהודית
(הופנה מהדף Off-the-Record Messaging)
קפיצה לניווט קפיצה לחיפוש

בקריפטוגרפיה, מיסור שלא לפרסום או מיסור שלא לציטוט (באנגלית: Off-the-Record Messaging, או בקיצור OTR),[1], הוא פרוטוקול קריפטוגרפי בקוד פתוח המספק הצפנה מקצה-לקצה למסרים מידיים. OTR משתמש בשילוב של מספר פרימיטיבים קריפטוגרפיים ידועים: צופן סימטרי AES עם מפתח באורך 128 סיביות, פרוטוקול שיתוף מפתח דיפי-הלמן עם מפתחות באורך 1536 סיביות וקוד אימות מסרים SHA1-HMAC המבוסס על פונקציית הגיבוב SHA-1. במקביל לאימות והצפנה, OTR מספק גם חשילות וסודיות מושלמת קדימה.

המניע העיקרי מאחורי פיתוח הפרוטוקול הוא לספק אימות וסודיות השיחה, אך בניגוד לכלי הצפנה נפוצים כמו SSL לאפשר גם "יכולת הכחשה", כך שלא יהיה באפשרות צד שלישי או אפילו המתקשרים עצמם להוכיח בעתיד מיהו מקור שיחה שנעשתה. OTR הועלה לראשונה במאמר שכותרתו: "תקשורת שלא לציטוט, או מדוע לא להשתמש ב-PGP"[2] שפורסם באוקטובר 2004 על ידי Nikita Borisov, Ian Goldberg ו-Eric Brewer מאוניברסיטת ברקלי. ההתעניינות בפרוטוקול OTR גברה בעקבות החשיפות המסעירות שליוו את פרשת סנודן, שה-NSA ביצע ועדיין מבצע האזנות סתר מאסיביות לאזרחי אצרות הברית ובכל העולם והוא משמש אבן דרך חשובה ומודל לחיקוי בהתפתחות ההצפנה המודרנית. השאיפה כיום להבטיח פרטיות באמצעות הצפנה חזקה באופן כזה שלא תהיה לגוף מרכזי כלשהו סמכות או יכולת להפר אותה ובד בבד להסתיר מעיני המשתמש הלא מיומן בנושאי אבטחת מידע את כל המנגנון הקריפטוגרפי המסובך. לאפשר שימוש חלק ואינטואיטיבי ללא צורך בהבנה יתרה של עיקרון התאורטי העומד מאחורי המערכת.

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

היסטוריה

OTR הוצע כאלטרנטיבה ל-PGP ומערכת S/MIME (אנ'), "בסדנא בנושא פרטיות בחברה האלקטרונית". הגרסה הראשונה 0.8.0 יצאה ב-21 בנובמבר 2004. בשנת 2005 מסמך שפורסם על ידי מריו ריימונדו, רוסאריו ג'נארו והוגו קרבצ'יק העלה מספר חולשות בפרוטוקול והציע תיקונים, בעיקר בחלק הקשור לשיתוף המפתח הנקרא בקיצור AKE (חילוף מפתח מאומת) שבגרסת הפרוטוקול המקורית היה חשוף להתקפת אדם באמצע. גם כן, האפשרות לפצל הודעות OTR על מנת להתמודד עם מערכות צ'אט בעלי גודל הודעה מוגבל, שיטה פשוטה של אימות נגד מתקפת האדם שבאמצע יושמה. במקום להשוות בין סיכום הביקורת לבין המפתח, ידיעה של סוד שרק שני הצדדים המשתתפים בשיחה יודעים אותו, יכול לשמש לאימות של שני הצדדים, משום שיש סבירות נמוכה שהתוקף ידע אותו. גרסה 3 של הפרוטוקול פורסמה בשנת 2012. כדאי להימנע ממצב שבו מספר מחשבים מתחברים לאותה שיחה עם אותו שם משתמש בו זמנית, נוצרה תווית זיהוי מדויקת יותר עבור כל משתמש שיושמה בגרסה 3. יתרה על כך, מפתח חדש נוצר שיוכל לשמש כערוץ נותנים נוסף. נכון ל-2016 הגרסה העדכנית ביותר היא libotr 4.1.1 וכן pidgin-otr 4.0.2 שמכילות מספר תיקונים בטיחותיים של הגרסאות הקודמות כמו גלישת חוצץ ומומלץ לעבור אליהן מיידית.

מוטיבציה ומאפיינים כלליים

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

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

  • סודיות קדימה. כל השיחות יהיו מוצפנות באמצעות מפתחות חד פעמיים קצרי טווח שנוצרים לפי הצורך באופן אקראי ומושמדים מיד לאחר השימוש הם נקראים מפתח שיחה או המפתח הארעי (באנגלית: Ephemeral key). לכן גם אם מפתח סודי ארוך טווח של אחד מהמשתתפים נחשף לא ניתן יהיה לעשות בו שימוש כדי לפענח שיחות שנעשו בעבר. כדי לשתף את המפתח החד-פעמי הם משתמשים בפרוטוקול דיפי-הלמן שמאפשר למשתתפים לשתף מפתח מעל גבי ערוץ פתוח הנתון לציתות מבלי לחשוף אותו לאף אחד. בקצרה, תחילה הם בוחרים מספר ראשוני גדול ויוצר של תת-חבורה של מסדר ראשוני גדול, שניהם גלויים ומפורסמים לכל. ואז אליס ובוב בוחרים את המפתחות הפרטיים שלהם שהם השלמים ו- בהתאמה ומשדרים אחד לשני את המפתחות הציבוריים שלהם שהם ו- מודולו בהתאמה. אליס יכולה כעת לחשב את המפתח המשותף על ידי הכפלה של המפתח הפרטי שלה עם המפתח הציבורי של בוב: ובאותה דרך בוב מחשב את המפתח על ידי (מודולו ). המפתח המשותף מודולו אינו ידוע לאיש מלבדם. ההנחה היא שמבחינה מתמטית כל עוד לא קיים מחשב קוונטי, קשה מאד לגלות את או את מתוך מודולו ולכן הסוד שלהם בטוח. אלא אם כן מישהו יגלה דרך מתוחכמת לפתור את בעיית הלוגריתם הבדיד או בעיית דיפי-הלמן הנחשבות לבעיות מתמטיות קשות מזה שנים רבות.
  • חתימה דיגיטלית. כדי להבטיח את זהות הצדדים המשתתפים בשיחה יש צורך בחתימה דיגיטלית כמו DSA או RSA. ההנחה היא שלכל משתמש חתימה דיגיטלית קבועה שבדרך כלל אמורה להחזיק מעמד שנים רבות. חתימה דיגיטלית מאושרת על ידי רשות מאשרת אינה ניתנת להכחשה, החתימה משמשת כהוכחה לשייכות התוכן החתום לחותם מבחינה חוקית. כאן מעוניינים להשיג בדיוק את ההפך לכן במקום לחתום על השיחות עצמן החתימה משמשת רק לאימות המפתחות הציבוריים ו- בהתאמה. בדרך זו כל אחד יכול לאמת שאכן אליס או בוב הם הבעלים של המפתחות הללו אך לא מעבר לכך. בכל אופן, בידי אליס ובוב קיים מידע נוסף והוא המפתחות הפרטיים שלהם, מידע זה שנשמר בסוד ישמש אותם לאחר מכן לאימות השיחות עצמן.
  • קוד אימות מסרים. קוד אימות בקיצור MAC מאפשר לאליס ובוב להבטיח את אותנטיות ומקור השיחות שלהם, אך בד בבד למנוע מצד שלישי מלהוכיח זאת בעצמו. התכונה של קוד אימות מסרים היא שבניגוד לחתימה דיגיטלית אינו מכיל אי-יכולת הכחשה, למעשה כל מי שיודע מהו המפתח הפרטי איתו הוכן קוד האימות יכול בעצמו להכין קוד אימות של תוכן כל שיחה אחרת. בקצרה, פונקציית אימות כמו HMAC היא פונקציה המקבלת את השיחה המיועדת לאימות ומפתח סודי ומפיקה תג אימות קצר אותו מצרפים לשיחה עצמה במהלך שידורה. המקבל משתמש בפונקציית האימות המתאימה, עם אותו מפתח סודי כדי לוודא באמצעות התג המצורף שאכן תוכן השיחה נותר שלם ואינו מכיל שינויים זדוניים על ידי צד שילישי כלשהו וכן שהשיחה אכן הגיעה מהמקור ממנו היא אמורה להגיע. לעומת זאת, למתבונן מהצד, אין בתג האימות כל מידע שיכול להוכיח ממי הגיעה השיחה. יתרה מזו, הפרוטוקול אף מכתיב לחשוף את מפתח האימות במכוון (לאחר שמקבל השיחה אישר שקיבל אותה), עובדה זו מוסיפה פרטיות כי לאחר קבלת השיחה ובדיקת תג האימות אין צורך במפתח האימות, כך שחשיפתו בעצם מטשטשת לחלוטין את הקשר בין מפתח האימות לבעל השיחה.
  • הצפנה חשילה. בנוסף ליכולת ההכחשה האמורה מנסים להשיג תכונה נוספת הנקראת חשילות או יכולת זיוף. כל השיחות מוצפנות באופן כזה שניתן יהיה לבצע מניפולציה שלהן מבלי שהדבר יתגלה. לעובדה זו שלכאורה נשמעת מנוגדת למטרה, יש חשיבות רבה כי היא בעצם מאפשרת לשלול כל הוכחה שתינתן בעתיד לגבי מקור השיחה כי כל אחד יכול היה "לזייף" את תוכנה. כמובן שהמשתתפים בשיחה בזמן אמת יכולים לוודא שלא נעשו שינויים כי בידם מפתח אימות סודי. לאחר מעשה, כאשר מפתח האימות נחשף אי אפשר להשתמש בו כדי להוכיח שהמסר המקורי לא שונה. אפשר להשיג זאת על ידי צופן זרם או במצב הפעלה של צופן בלוקים המדמה צופן זרם כמו מצב מונה. צופן זרם מצפין את המידע על ידי XOR עם מפתח הצפנה באורך המידע עצמו, סיבית אחר סיבית או מילה אחר מילה. ההשפעה של מניפולציות (היפוך סיביות) של הטקסט המוצפן משפיעה אך ורק על הסיביות המתאימות בטקסט המקורי לאחר פענוח. אם מישהו מצליח לנחש חלק מהטקסט המוצפן ביכולתו לשנות את הטקסט המוצפן למה שיחפוץ אפילו מבלי לגלות את מפתח ההצפנה.

מהלכי הפרוטוקול

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

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

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

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

באופן תמציתי שיחת OTR יכולה להראות כך:

וכן הלאה. כאשר מייצג הצפנה באמצעות AES במצב מונה.

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

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

שיתוף מפתח מאומת

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

(1)

כאשר הוא הצפנת AES של המפתח הציבורי הארעי של דיפי הלמן ( הוא ערך אקראי חד פעמי המשמש כמפתח הצפנה) ו- היא פונקציית גיבוב. אליס מחזירה לבוב את:

(2)

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

(3)

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

(4)

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

בעיית המיליונרים

החסרון בפרוטוקול AKI הוא שבכל שלבי הפרוטוקול ההנחה היא שאליס מכירה את בוב ויודעת מהו המפתח הציבורי שלו וכן בוב מכיר את אליס ויודע מהו המפתח הציבורי שלה. אך אם בוב לא מכיר את אליס או שאליס אינה מכירה את בוב איב יכולה להתחזות לאחד מהם בקלות על ידי ביצוע כל מהלכי הפרוטוקול המתוארים אך עם המפתחות שלה במקום של אליס או בוב. ההתחזות לא תתגלה אלא אם כן אליס או בוב ינסו לברר מהו המפתח הציבורי שלהם באמצעים אחרים מחוץ לפרוטוקול. התקפה כזו קלה לביצוע במיוחד על ידי גורם מרכזי שיש לו שליטה על שרת ההודעות. למעשה קיים תוסף ל-Jabber (כיום נקרא XMPP) הנקרא mod_otr שמבצע באופן אוטומטי התקפת אדם באמצע נגד שיחת OTR[3]. כדי לסכל את ההתקפה אפשר לפעול בדרך פשוטה. כל משתמש יאחסן רשימה של המפתחות הציבוריים של כל החברים איתם הוא משוחח. במידה שמצטרף לשיחה חבר חדש שהמפתח שלו אינו מוכר (לא נמצא ברשימה), תופיע התראה שמבקשת מהמשתמש לוודא שהמפתח נכון. למעשה OTR הציג למשתמש "טביעת אצבע" בדמות QR של תוצאת הפונקציה SHA-1 של המפתח הלא מוכר והמשתמש נדרש להשוות את טביעת האצבע מול טביעת אצבע שהוא השיג בעצמו באמצעים אחרים (מחוץ למהלכי הפרוטוקול). הבעיה היא שרוב המשתמשים לא מבינים את משמעות טביעת האצבע, הם מעדיפים להתעלם מההודעה או מנסים להשוות רק מספר בתים מתחילת טביעת האצבע ומספר בתים מסופה. מה שמאפשר התקפה מצד איב עם מפתח ציבורי הדומה למפתח הציבורי של אליס או בוב רק בבתים הראשונים והאחרונים. בנוסף השאיפה היא להסתיר מעיני המשתמש את המנגנון הקריפטוגרפי המסובך שפועל מאחורי הקלעים ולדמות שימוש חלק ככל האפשר בתוכנת המסרים כאילו לא היה קיים.

הפתרון שננקט ב-OTR גרסה 3 ומעלה הוא שימוש בפרוטוקול משני הנקרא "פרוטוקול המיליונרים הסוציאליסטיים" בקיצור (SMP) שהוא עצמו וריאציה של בעיית המיליונרים שניתן לה פתרון מעשי על ידי Yao[4]. ב-2001 פורסם פתרון יעיל לבעיית המיליונרים הסוציאליסטיים על ידי Boudot, Schoenmakers, ו-Traoré בהתבסס על בעיית הכרעת דיפי-הלמן בקיצור DDH[5]. הפתרון מאפשר לשני מיליונרים לדעת האם עושרם שווה מבלי לחשוף את עושרם המדויק לאף אחד מהצדדים או לצד שלישי. במילים אחרות זהו פרוטוקול כמעט אפס ידיעה שבו המידע הנחשף בסיומו שווה לסיבית אחת בלבד - אמת או שקר. בהקשר של OTR במקום להשוות כסף, משווים את המידע המשותף לאליס ובוב. אם איב המנסה להתחזות לאליס לא תצליח לנחש נכון את הסוד בניסיון הראשון הפרוטוקול יסתיים מיד בכישלון. לכל היותר איב תצליח לשבש או לקטוע זמנית את השיחה בין אליס ובוב. כדי למנוע מאיב מלהונות את המשתתפים על ידי העברת חילופי המסרים של פרוטוקול SMP כלשונם מאחד לשני הסוד אותו משווים כולל טביעת אצבע עם SHA-2 של מזהה השיחה, טביעות האצבע של מפתחות שני הצדדים והסוד המשותף. במצב כזה רוב הסיכויים שהתקפת MITM תכשל מיד משום שאצל בוב ואליס יתקבלו טביעות אצבע שונות. בד בבד הפרוטוקול מבטיח שאף אחד לא יוכל ללמוד מאומה מחלופי המסרים על הסוד המשותף שלהם מעבר לעובדה שהוא שווה אצל שניהם. כל התהליך מתרחש מאחורי הקלעים ללא מעורבות המשתמשים עצמם.

פרוטוקול SMP

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

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

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

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

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

סוד משותף

חלון אימות חבר של תוסף OTR לתוכנת המסרים פיג'ין באמצעות סוד משותף

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

ביטחון

ראו גם

קישורים חיצוניים

הערות שוליים

  1. ^ Off-the-Record Messaging
  2. ^ Off-the-Record Communication, or, Why Not To Use PGP, Nikita Borisov, Ian Goldberg, Eric Brewer, 2004
  3. ^ Olivier Goffart. mod_otr — Man in the Middle module for Off-The-Record. http://ejabberd.jabber.ru/mod_otr. Accessed June 2007
  4. ^ Andrew Yao. Protocols for secure computations. In Proceedings of the 23rd IEEE Symposium on Foundations of Computer Science, pages 160–164, 1982
  5. ^ Fabrice Boudot, Berry Schoenmakers, and Jacques Traoré. A Fair and Efficient Solution to the Socialist Millionaires' Problem. Discrete Applied Mathematics, 111(1–2):23–36, 2001
  6. ^ Claus-Peter Schnorr. Efficient signature generation by smart cards. Journal of Cryptology, 4(3):161–174, 1991
  7. ^ Markus Jakobsson and Moti Yung. Proving Without Knowing: On Oblivious, Agnostic and Blindfolded Provers. In Proc. of Advances in Cryptology—CRYPTO ’96, Lecture Notes in Computer Science 1109, pages 186–200, 1996
  8. ^ Tero Kivinen and Mika Kojo. More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). RFC 3526, May 2003
הערך באדיבות ויקיפדיה העברית, קרדיט,
רשימת התורמים
רישיון cc-by-sa 3.0

22886803מיסור שלא לפרסום