Secure Boot

«חזרה לאינדקס המונחים

הסבר על המושג Secure Boot

Secure Boot (אתחול מאובטח) הוא תקן אבטחה ותכונה של ממשק ה-UEFI (Unified Extensible Firmware Interface) שנועד למנוע מתוכנות זדוניות, כגון Bootkits ו-Rootkits, להיטען במהלך תהליך האתחול של המחשב. בניגוד ל-BIOS המסורתי, שהציע הגנה מועטה מפני תוכנות זדוניות טרם-האתחול (pre-boot malware), ה-Secure Boot יוצר שרשרת אמון (chain of trust) על ידי אימות החתימות הדיגיטליות של כל פיסת תוכנה שרצה לפני טעינת מערכת ההפעלה (OS). זה מבטיח שרק תוכנה מהימנה ומאומתת תורשה לפעול.

איך זה עובד

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

1. הפעלה ואתחול UEFI: כאשר אתה מפעיל את המחשב, קושחת ה-UEFI מבצעת אתחול. היא בודקת אם Secure Boot מופעלת וטוענת סט של מפתחות ושל מסדי נתונים קריפטוגרפיים מהזיכרון הבלתי נדיף (NV-RAM) של המחשב.
2. בדיקת מסדי נתונים ומפתחות: קושחת ה-UEFI משתמשת במספר מסדי נתונים כדי לנהל את האמון:
   • מסד נתוני חתימות מורשות (db): מסד נתונים זה מכיל את החתימות הקריפטוגרפיות או הגיבובים (hashes) של תוכנות מהימנות ורכיבים מורשים, כמו מנהלי אתחול של מערכת ההפעלה, מנהלי התקנים של UEFI (דרייברים) ויישומים.
   • מסד נתוני חתימות שבוטלו (dbx): מסד נתונים זה מכיל חתימות של תוכנות זדוניות או מוכרות כרעות, שאסור להן לרוץ. אם חתימה של תמונה (image) נמצאת גם ב-db וגם ב-dbx, היא נחסמת.
   • מפתח החלפת מפתחות (KEK – Key Exchange Key): סט של מפתחות שניתן להשתמש בהם כדי לעדכן את מסדי הנתונים db ו-dbx. מיקרוסופט, למשל, דורשת שה-KEK שלה ייכלל בכל המחשבים שקיבלו הסמכה ל-Windows 8 ומעלה, כדי שתוכל להוסיף מנהלי אתחול חדשים או לבטל כאלה שידועים כרעים.
   • מפתח הפלטפורמה (PK – Platform Key): המפתח ברמה הגבוהה ביותר, השולט על כל תהליך ה-Secure Boot וניתן להשתמש בו כדי לעדכן את מסד הנתונים KEK. יצרן המחשב (OEM) שולט במפתח זה כברירת מחדל, אך משתמשים יכולים לעיתים קרובות להחליף אותו כדי לקבל שליטה מלאה על מדיניות האתחול של המערכת שלהם.
3. אימות חתימה: הקושחה בודקת את החתימה הדיגיטלית של פיסת תוכנת האתחול הראשונה שהיא טוענת, כגון מנהל האתחול של מערכת ההפעלה (לדוגמה, Windows Boot Manager או מנהל אתחול לינוקס כמו GRUB). החתימה מושווית למפתחות במסדי הנתונים db ו-dbx.
   • אם החתימה תקפה ואינה ב-dbx, הקושחה מאפשרת למנהל האתחול לרוץ.
   • אם החתימה אינה תקפה, חסרה, או נמצאת ב-dbx, הקושחה עוצרת את תהליך האתחול ומציגה הודעת שגיאה.
4. שרשרת אמון: תהליך זה נמשך כאשר מנהל האתחול משתלט על התהליך ומאמת את החתימות הדיגיטליות של הרכיבים הבאים, כגון ליבת מערכת ההפעלה (OS kernel) והדרייברים. זה יוצר שרשרת אמון המשתרעת מהקושחה ועד לטעינת מערכת ההפעלה, ומבטיחה שאף קוד לא מורשה לא בוצע בדרך. [יש לצרף תמונה של תרשים זרימת תהליך Secure Boot]

   

לדוגמה, בעת אתחול מחשב Windows, קושחת ה-UEFI משתמשת במפתחות המהימנים שלה כדי לאמת את החתימה של Windows Boot Manager. לאחר מכן, ה-Windows Boot Manager מאמת את החתימה של ליבת Windows ושל רכיבים קריטיים אחרים. אם אחת מהבדיקות הללו נכשלת, תהליך האתחול נעצר, ומונע מרכיב נגוע בתוכנה זדונית להיטען.

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

סוגי Secure Boot

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

• Secure Boot OEM סטנדרטי: זהו היישום הנפוץ ביותר, שבו יצרן המחשב (OEM) שולח את המחשב עם Secure Boot מופעל ומצויד במפתחות שלו ושל שותפים כמו מיקרוסופט. תצורה זו היא הסטנדרט במחשבים ניידים ונייחים ונותנת הגנה מיידית ל-Windows.
• Secure Boot מותאם אישית: חומרה מסוימת מאפשרת למשתמשים מתקדמים לנהל את מפתחות ה-Secure Boot שלהם בעצמם. זה אומר שאתה יכול למחוק את המפתחות המוגדרים כברירת מחדל ולרשום מפתחות משלך, שבהם תוכל להשתמש כדי לחתום על מנהלי אתחול, ליבות או דרייברים מותאמים אישית. זה מציע שליטה רבה יותר אך דורש מומחיות טכנית ומשמש לעתים קרובות מפתחים או חובבים שרוצים להריץ תוכנה מותאמת אישית או לא נתמכת.
• Verified Boot (אתחול מאומת): תכונה זו משמשת לעיתים קרובות בהקשר של מכשירים ניידים ומערכות סגורות אחרות (כמו מכשירי IoT), והיא דומה ל-Secure Boot אך יכולה לנקוט בגישה אגרסיבית יותר. במקום רק לחסום קוד לא חתום, היא עשויה גם למדוד ולתעד את הגיבובים של כל הרכיבים שנטענו כדי ליצור בסיס של מצב מערכת "ידוע כתקין". זה חיוני עבור מכשירים שבהם כל שרשרת האתחול חייבת להיות מוגנת מפני התקפות פיזיות או רשתיות.

יתרונות וחסרונות

כמו כל תכונת אבטחה, ל-Secure Boot יש יתרונות וחסרונות.

יתרונות

• הגנה מפני Rootkits ו-Bootkits: מטרתו העיקרית היא לחסום תוכנות זדוניות שמנסות להדביק את השלבים המוקדמים של תהליך האתחול, שהם בלתי נראים לתוכנות אנטי-וירוס מסורתיות.
• שיפור שלמות המערכת: הוא מבטיח שרכיבי הליבה של מערכת ההפעלה לא שונו או הוחלפו על ידי תוכנה לא מורשית, ויוצר בסיס מאובטח למערכת ההפעלה.
• תקן תעשייתי: Secure Boot הוא תקן שאומץ באופן נרחב ונדרש עבור הסמכת Windows 11, מה שהופך אותו לתכונת אבטחה מובנית וצפויה במחשבים מודרניים.
• משפר אבטחה כללית: על ידי מניעת התקפות ברמה בסיסית, Secure Boot הופך את כל המערכת לעמידה יותר בפני מגוון רחב של איומי סייבר.

חסרונות

• בעיות תאימות: Secure Boot יכול להוות מחסום למשתמשים שרוצים להתקין מערכת הפעלה שאין לה מנהל אתחול חתום או להשתמש בדרייברים לא חתומים. זוהי בעיה נפוצה עבור חלק מהפצות לינוקס או גרסאות ישנות יותר של מערכות הפעלה.
• צמצום חופש המשתמש: כברירת מחדל, Secure Boot מעביר את השליטה על תהליך האתחול ליצרן המחשב (OEM) ולספקית מערכת ההפעלה. אף על פי שניתן בדרך כלל לבטל אותו בהגדרות ה-UEFI/BIOS, פעולה זו יכולה לחשוף את המערכת לסיכוני אבטחה.
• מורכבות: עבור המשתמש הממוצע, ניהול או פתרון בעיות של Secure Boot יכול להיות מורכב. אם תהליך האתחול נכשל עקב חתימה לא תקפה, קשה לאבחן את הבעיה ללא ידע טכני.
• לא פתרון מלא: Secure Boot אינו "כדור כסף" לכל בעיות האבטחה. הוא מגן רק על סביבת טרום-האתחול. ברגע שמערכת ההפעלה פועלת, המערכת עדיין פגיעה לסוגים אחרים של תוכנות זדוניות והתקפות. זוהי חתיכה קריטית באסטרטגיית אבטחה גדולה יותר, שצריכה לכלול גם תוכנות אנטי-וירוס, חומות אש ועדכונים קבועים.

«חזרה לאינדקס המונחים