אימות מסרים

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

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

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

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

עריכה

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

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

קוד אימות מסרים

עריכה
  ערך מורחב – קוד אימות מסרים

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

 

ושולח את   למקבל והמקבל בתורו מוודא את שלמות המסר   על ידי חישוב פונקציית האימות:

 .

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

חתימה דיגיטלית

עריכה
  ערך מורחב – חתימה דיגיטלית

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

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

עריכה

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

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

ראו גם

עריכה

הערות שוליים

עריכה
  NODES
Verify 2