המניע העיקרי מאחורי פיתוח הפרוטוקול הוא לספק אימות וסודיות השיחה, אך בניגוד לכלי הצפנה נפוצים כמו SSL לאפשר גם "יכולת הכחשה", כך שלא יהיה באפשרות צד שלישי או אפילו המתקשרים עצמם להוכיח בעתיד מיהו מקור שיחה שנעשתה. OTR הועלה לראשונה במאמר שכותרתו: "תקשורת שלא לציטוט, או מדוע לא להשתמש ב-PGP" שפורסם באוקטובר 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 אינם בנויים לספק מאפיין זה. את היעדים האמורים אפשר להשיג בדרך הבאה:
מהלכי הפרוטוקול.
כדי לצמצם את חלון הזמן שבו מפתח השיחה חשוף להתקפה, מנסים להחליף אותו בתדירות הגבוהה ביותר האפשרית. במרבית המכשירים בימינו קיים מעבד די חזק המסוגל לבצע פעולות אריתמטיות במספרים ארוכים בתוך זמן מאוד קצר, כמספר מילישניות. עובדה זו מאפשרת החלפת מפתח שיחה בשיטת דיפי-הלמן לאחר כל הודעה. כל מהלך של שיתוף מפתח דורש בסך הכול שתי העלאות בחזקה מודולו מספר ראשוני גדול. אפילו התקנים בעלי משאבים מאוד נמוכים יכולים לבצע זאת מבלי שהמשתמש יבחין בעיכוב כלשהו. כדי לחסוך בהודעות הפרוטוקול מנצל את ההודעות המכילות את מסרים בין אליס ובוב כדי להעביר גם את החומר המיועד להכנת מפתח השיחה הבא. למעשה הודעה מאליס לבוב תכיל את המסר אותו היא מעוניינת להעביר לו יחד עם מפתח ציבורי חדש שישמש את בוב כדי לגזור ממנו מפתח משותף בשיטת דיפי הלמן להצפנת ההודעה הבאה וכאשר הוא מחזיר לה תגובה, הוא מצרף אליה את החלק שלו להכנת המפתח המשותף הבא וכן הלאה. כזכור מפתח השיחה הוא כפולה של המפתחות הציבוריים עם המפתחות הפרטיים הנגדיים (מודולו המספר הראשוני), לכן אין במפתח הזה כל מידע שיכול לשמש את המצותת איב אפילו שהוא מכיל מחצית מהמידע הדרוש להכנת מפתח השיחה. כל עוד המפתחות הפרטיים של שני הצדדים לא נחשפו הסוד המשותף נותר בטוח.
לצורך תיאור הפרוטוקול, נניח שאליס רוצה לשלוח את המסר "HELLO" כשהוא מוצפן לבוב. נניח שהמפתח הציבורי הטרי ביותר של אליס הוא formula_20 אליו משויך המספר הסידורי formula_21, נניח עוד שבוב שלח לאליס קודם לכן את המפתח הציבורי שלו formula_22 יחד עם המזהה הייחודי שלו (המפתח האחרון של כל אחד מהם יכול להיות זה שנוצר בעת הרצת פרוטוקול AKE המתואר להלן או שהוא מפתח חדש שהתקבל במסגרת חילופי ההודעות ביניהם). היא מבצעת את המהלכים הבאים:
במילים, אליס שולחת לבוב מסר המורכב ממספר חלקים; החלק הראשון מכיל את גוף ההודעה כשהוא מוצפן באמצעות הצופן הסימטרי במצב מונה עם המפתח והמונה שהכינה, את המפתח הציבורי שלה לצורך ההודעה הבאה, מזהי המפתחות הציבוריים שלה ושל בוב והמונה ששימש אותה להצפנת ההודעה. החלק השני מכיל את תג האימות של ההודעה שהוכן באמצעות פונקציית MAC. והחלק השלישי הוא מפתח האימות הישן שאיתו השתמשה כדי לאמת את ההודעה הקודמת ואין לה צורך בו יותר. המטרה של שליחת המפתח היא רק כדי לחשוף אותו כך שאף אחד לא יכול להוכיח בעתיד מי היה מקור ההודעה. כי אם מפתח האימות הסימטרי ידוע לכולם, כל אחד יכול להכין הודעה מזויפת ולייצר לה תג אימות מתאים עם מפתח זה, אך מרגע שהמפתח נחשף אין בזה כל הוכחה לכך שמקור ההודעה מאליס. בוב מצידו מייצר מפתח דיפי הלמן חדש מהמפתח הציבורי של אליס המסומן בתווית formula_21 והמפתח הפרטי שלו המסומן בתווית formula_33 ומקבל את מפתח ההצפנה formula_25 (אותו מפתח בדיוק שיצרה אליס) איתו הוא מפענח את החלק המוצפן של ההודעה formula_35, בודק שהיא תקינה על ידי תג האימות המצורף וקורא את ההודעה המיועדת אליו. ואותו תהליך חוזר על עצמו באופן דומה הפעם מצד בוב.
באופן תמציתי שיחת OTR יכולה להראות כך:
וכן הלאה. כאשר formula_36 מייצג הצפנה באמצעות AES במצב מונה.
במהלכי הפרוטוקול המתוארים מתרחש תהליך שיש המכנים אותו מחגר משונן (ראצ'ט) בדומה לכלי העבודה לחיזוק ברגים שמסתובב רק בכיוון אחד. בכל הודעה, השולח מצרף אליה את מפתח שלו להצפנת ההודעה הבאה והמקבל מצידו כאשר הוא מחזיר הודעה לשלוח הוא מצרף אליה את המפתח שלו להצפנת ההודעה הבאה וכן הלאה. כך הפרוטוקול "מסתובב" באופן חד כיווני. בכל נקודת זמן, אם התגלה מפתח שיחה אחד, אין בו די מידע המאפשר לנחש את מפתח השיחה הקודם כי הוא נוצר מחדש בתהליך דיפי-הלמן והמפתח שלפניו הושמד. כדי שאליס או בוב יהיו משוכנעים שהם מקבלים מפתח ציבורי אחד של השני ולא של מתחזה שנכנס באמצע, כל מפתח דיפי הלמן חדש מאומת באמצעות תג אימות שנגזר מהמפתח הקודם. אם המתחזה אינו יודע מהו מפתח השיחה כי הוא מעולם לא נשלח בגלוי, תהיה לו בעיה לשכנע אחד מהם שהמפתח שייך לבוב או אליס כי תג האימות יגלה מיד אם זה נכון. במילים אחרות, תהליך האימות מתבצע בשני מישורים, תחילה מבוצע אימות מלא של המפתח הראשון המסתמך על חתימה דיגיטלית של שני הצדדים המתקשרים. במישור השני מתבצע אימות חלקי באמצעות תג אימות סימטרי המסתמך על ההנחה שמפתח השיחה הראשוני לא נחשף. וכמובן בנוסף לאמור לעיתים אחד מהצדדים ידרוש לבצע את פרוטוקול SMP המתואר כדי לסכל ליתר ביטחון התקפת אדם באמצע.