החזירו אותם הביתה עכשיו

קצת על קריפטוגרפיה

בתיקנון מנגנון DNSSEC הוגדר כיצד לשלב קריפטוגרפיה בפרוטוקול DNS:

  • כיצד לחתום דיגיטלית על רשומות DNS (בצד השרת)
  • כיצד לאמת את החתימות הנ"ל (בצד הלקוח)

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

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

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

חתימה דיגיטלית היא אם כן פעולת חתימה ממוחשבת.

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

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

זה מחייב הסכמה על סוד (מפתח) בין שני הצדדים (המצפין והמפענח).

הצפנה א-סימטרית: ההצפנה והפענוח נעשים ע"י מפתחות שונים.
הצד המצפין והצד המפענח לא נדרשים להסכים על סוד (לא מחליפים ביניהם מפתח).

הצפנה א-סימטרית היא כיום חלק בלתי נפרד מהפעילות ברשת האינטרנט, ומשמשת לגלישה (SSL/TLS), ניתוב (RPKI), מטבעות קריפטו, VPN, וכו'

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

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

הערות:

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

הצפנה א-סימטרית:

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

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

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

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

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

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

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

ביצוע פעולות קריפטוגרפיות מחייבת שמירה על מספר עקרונות

1.      שמירה על סוד

יש להגן על המפתח הפרטי!

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

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

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

2.      יכולת לחולל מפתחות חזקים

 חוזק הצופן תלוי באלגוריתם ההצפנה ובאורך המפתחות.
אלגוריתם RSA/SHA256 עם מפתחות באורך 1024 לפחות הינו האופציה הוותיקה, אולם כיום, ב- DNSSEC היא פחות מועדפת. אלגוריתם  ECDSA P-256 יעיל הרבה יותר, מספק הגנה טובה יותר, באמצעות מפתחות קטנים בהרבה (מפתח EC באורך 256 שקול מבחינת חוזקו למפתח RSA באורך 3072) זהו יתרון משמעותי במערכת אונליין מהירה כמו DNS.

3.      החלפת מפתחות באופן מחזורי

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

4.      וידוא תקינות חתימה

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

5.      מנגנון אמון

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

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

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