אימות מסרים

בתורת האינפורמציה ובקריפטוגרפיה, אִמּוּת מְסָרִים (באנגלית: Message Authentication), שְׁלֵמוּת או כְּלִילוּת מְסָרִים (באנגלית: Message Integrity), מתייחסים למאפיין זיהוי מקור המסרים העוברים ברשת והגנה מפני שינויים זדוניים של תוכנם במהלך העברתם, באופן שהמקבל יכול להבחין בהם לדחותם על הסף ולהחזיר התראה מתאימה לשולח.
הצפנה לבדה אינה מספקת אימות והבטחת שלמות כלל. בעוד שההצפנה יכולה להבטיח את סודיות המידע היא אינה בהכרח מעידה על שלמותו ועל שייכותו לגורם כלשהו. לפעמים לא פחות חשוב ואולי אף יותר חשוב, להבטיח את שלמות המידע ולאמת את מקורו מאשר להגן על סודיותו, הדוגמה הטובה ביותר היא עדכוני תוכנה שעלולים להכיל וירוסים רוגלות ונוזקות אחרות. למרות שהבטחת שלמות ואימות הם מושגים מעט שונים, בהקשר של אימות מסרים הם משולבים יחד כי כמעט תמיד הבטחת שלמות משליכה בהכרח על זיהוי ואימות מקור המסמך או המסר. אפשר להשיג הבטחת שלמות ואימות באמצעות שתי שיטות עיקריות: בשיטה הסימטרית באמצעות קוד אימות מסרים או בשיטה האסימטרית באמצעות חתימה דיגיטלית בשילוב עם פונקציית גיבוב.
יש להבחין בין שני מצבים: מצב בו המידע אינו אמור להיות סודי אך המקבל בכל זאת מעוניין להבטיח את שלמותו ואת זהות השולח. ומצב הצפנה עם אימות, המשלב גם סודיות וגם הבטחת שלמות ואימות המסרים המוצפנים. האחרון נקרא הצפנה מאומתת. לעיתים קרובות המידע העובר ברשת מכיל את שניהם יחד. חלק גלוי המיועד לטיפול על ידי מנהל הרשת כחלק מפרוטוקול התקשורת וחלק מוסתר המכיל את המידע עצמו. מקרה זה נופל בקטגוריה הצפנה מאומתת עם מידע נלווה והיא פופולרית ברשתות תקשורת מודרניות. הרעיון הוא שבמקרה כזה יש להבטיח את שלמות המידע הנילווה הגלוי באופן כזה ששינוי זדוני שלו לא יסכן את סודיות המידע המוסתר.

הצפנה לעומת אימות

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

התקפת שידור חוזר

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