לקבלת יעילות באבטחה יש צורך ביותר מאשר תאימות לרשימת בדיקות

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

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

מימוש של אבטחה שונה מאוד מביצוע אינטגרציה עם בלוקים של נכסים אינטלקטואליים (IP) של צד שלישי, כגון הוספת רשת Ethernet בתכנון מערכת על שבב SoC. בלוק רשת Ethernet עומד בתקן מסוים ויש לו ממשק חיצוני מוגדר כגון RMII/MII. לבלוק יש גם ממשק פנימי מוגדר כגון, AXI או AHB כדי להתחבר לחיבורים הפנימיים של המערכת (איור 1). בזכות הממשקים הסטנדרטיים האלו, מעט מאוד עלול להשתבש.

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

כמה מבין אותות פס צד אלו, שאינם סטנדרטיים, כוללים:

אותות מאובטחים ולא מאובטחים או אותות פולשניים ולא פולשניים ממעבד בעל יכולות של אזור מאובטח (trust zone), (כמו למשל משפחת Cortex-A של ARM), אשר מנותבים אל בקר ניפוי השגיאות של המערכת או אל בקר מרכזי אחר, אם קיים כזה.

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

אותות אזהרה מפני ניסיונות חבלה (tamper) מחיישנים על השבב ומחיישנים שמחוץ לשבב אל זיכרון אחסון המפתח הראשי (master key) באזור הסוללה (עבור מקרים שבהם יש להשתמש במפתח כאשר אספקת המתח הראשית לא זמינה או שנותקה).

אותות ייעודיים להעברת המפתחות הראשיים (master key) (מאזור הסוללה) אל מנוע ההצפנה.

אותות פס הצד ממודול JTAG/ניפוי שגיאות מאובטח, אשר חוסם גישה למערכת בהתבסס על תכונות אבטחה שונות.

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

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

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

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

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

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

דוגמה נוספת היא מפרט PTS של תעשיית כרטיסי התשלום (PCI) המשמש עבור מסופי נקודות המכירה (PoS). בהמשך מופיע חלק מהמפרטים האלו (מספר דרישה: A3):

אבטחת ההתקן לא נפגעת אם משנים את:

תנאי הסביבה

תנאי ההפעלה

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

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

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

עם זאת, הדרישות המפורטות לעיל פותחות שטח אפור: כיצד אפשר לפרש שינויים באות השעון כחלק “מתנאי ההפעלה”? כחלק מאחת ההתקפות האפשריות, ייתכן שמישהו יפעיל למשל יתר אות שעון (over clock) ועדיין יעמוד בדרישות המתוארות לעיל.

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

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

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

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

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