14.3.4. הערה על הגנת קריאה מזיכרון פלאש (flash)

מתוך הקופסה, הקושחה במצלמת OpenMV שנשלחת ניתנת לקריאה על ידי כל מי שיש לו גישה פיזית להתקן. תוקף שמחזיק את המצלמה בידיו יכול לחבר בדיקת SWD למחבר הניפוי, לתקשר עם ממשק הניפוי של ה-MCU, ולשפוך את זיכרון הפלאש (flash) – הכולל כל מודול Python מוקפא ואת תוכן מחיצת ROMFS. קושחת OpenMV הרגילה אינה מפעילה הגנת קריאה מזיכרון פלאש (flash) כברירת מחדל.

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

14.3.4.1. מה המצלמה עושה כברירת מחדל

המאתחל (bootloader) של המצלמה וסביבת הריצה שלה אינם מפעילים שום מנגנון הגנת קריאה של ה-MCU הבסיסי. ממשק הניפוי נשאר פתוח, זיכרון הפלאש (flash) נשאר קריא, וה-build רץ כפי שהוא רץ על שולחן העבודה של המפתח. זוהי ברירת המחדל הנכונה עבור קהל המדריך – מצלמה שנשלחת כשהגנת הקריאה מופעלת היא מצלמה שלא ניתן לבצע לה reflash דרך ה-IDE, לא ניתן לבצע לה re-image לאחר פריסה כושלת, ולא ניתן לשחזר אותה על ידי איש מלבד צוות ה-build.

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

14.3.4.2. מה צוות המוצר עושה

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

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

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

  • ההתחייבות היא בלתי-הפיכה. אין דרך להחזיר את המצלמה למצב שניתן לנפותו מבלי להשמיד אותה.

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

זהו החלק הקל.

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

  • את ה-REPL של MicroPython. REPL מחובר-USB מקבל Python שרירותי. הגנת קריאה אינה משנה זאת. הפעלת REPL יכולה לקרוא RAM, לקרוא לפונקציות, להוציא כל מה שהיישום הרץ יכול לראות – למעשה, REPL נגיש עוקף את כל מה שהגנת הקריאה מקנה. השבתת גישת REPL היא שינוי ב-build של הקושחה שצוות המוצר אחראי עליו.

  • העלאת סקריפט מה-IDE. נתיב ”הרץ סקריפט זה על המצלמה“ של ה-IDE רוכב על אותו משטח פרוטוקול USB שה-REPL רוכב עליו. סגירת ה-REPL סוגרת גם את זה; השארת אחד מהם פתוח משאירה ערוץ הרצת-קוד-שרירותי אל תוך המצלמה.

  • חטיפת נקודת הכניסה ממערכת הקבצים. כבר סגורה כאשר היישום נשלח דרך הקפאת סקריפטים אל תוך הקושחה – סביבת הריצה מאתרת את boot.py ו-main.py המוקפאים לפני כל עותק במערכת הקבצים, כך ששום דבר שמושלך בזיכרון הפלאש (flash) או בכרטיס SD אינו יכול לדרוס אותם. הגנה זו חינמית ברגע שהיישום נמצא ב-build.

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

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

מדוע ברירת המחדל פתוחה

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

14.3.4.3. מה גישה פיזית עדיין מקנה

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

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

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

  • במקרים מסוימים, לחלץ סודות באמצעות הזרקת-תקלות או התקפות ערוץ-צדדי המתמחות נגד ה-MCU המוגן.

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

14.3.4.4. עם מה קושחת OpenMV נשלחת

סיכום, כדי שזה יהיה קונקרטי:

  • אין הגנת קריאה מופעלת כברירת מחדל.

  • אין דגל build בקושחה הרגילה שמפעיל אותה.

  • אין API ברמת-היישום לקרוא לו מ-MicroPython.

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