חיים כהן, Freescale
מבוא: כאשר העולם מתפתח לקראת קישוריות אלחוטית, יצרני מוצרים חייבים למצוא דרכים לאבטח את הקניין הרוחני (IP) שלהם ולהגן עליו. מאמר זה עוסק בתפקיד החשוב של אבטחה בתוך מערכות מוטבעות ובאופן שבו הפתרונות של Freescale יכולים לעזור ללקוחות לנהל עידן חדש זה של חוסר ודאות. אף שחלל הצרכנים ממריץ את האימוץ של פתרונות אבטחה, מאמר זה מפרט גם פלחי שוק כגון כלי רכבת רשתות ותעשייה שבהם הצורך באבטחה חזקה הולך וגדל במהירות. המסמך מתחיל בסקירה היסטורית קצרה של הטמעת אבטחה ומפרט את המורשת של Freescale בפיתוח פתרונות קניין רוחני כדי לעמוד באתגרי האבטחה החדשים, דרך בעיות נפוצות שבהן נתקל מעצב המוצר. מסמך זה מתמקד באבטחה (המניעה של מניפולציה זדונית) ולא בבטיחות (הגנה מפני כשלים טכניים).
מורשת האבטחה של Freescale
בסוף שנות ה-90 של המאה ה-20, עם הדרישות הגדלות במהירות של טכנולוגיה סלולרית ופריסת נתונים באוויר, המחסור באבטחה התחיל להשפיע לרעה על התעשייה. חברות סלולריות טיפלו במחסור באבטחה על ידי הגדרת חסימות אבטחה ספציפיות של קניין רוחני. בתור מגזר המוליכים למחצה של מוטורולה לשעבר, Freescale פיתחה טכנולוגיות ספציפיות כדי למלא את דרישות האבטחה ההולכות וגוברות של מכשירים סלולריים ותשתיות רשת. כמאמץ משולב, קבוצה לפיתוח IC נוצרה כדי לשתף קניין רוחני ותשתית במטרה ליצור יכולות ויישומים מתקדמים לפלחי השיווק הסלולריים ואלה של רשתות. יותר מ-10 שנים לאחר מכן, צוות אבטחת IC של Freescale ממשיך לפרוס מומחיות חזקה ולקדם את המורשת של פתרונות אבטחה של החברה. עם פריסת פתרונות אבטחה בשווקים של כלי רכב, רשתות ותעשייה, Freescale נמצאת במיקום המאפשר לה להוביל במגזר זה הישר אל העתיד.
התגברות על אתגרי אבטחה
הרשימה של אתגרי אבטחה פוטנציאליים אינה קצרה כלל. טכנולוגיה אלחוטית, תוכנות עם מקור פתוח ופרוטוקול אינטרנט מפשטים את האפשרות של שינוי מידע. לשלושה איומים יש פוטנציאל להיות בעייתיים:
ציתות: מישהו ניגש למידע מבלי לשנות אותו. משתמש הקצה יכול לקבל החלטה מבלי לדעת שמישהו אחר ראה מידע רגיש, והתוצאה היא נזקים פיננסיים ואישיים חמורים למשתמש הקצה.
טיפול לרעה: מישהו משנה מידע ללא אישורו של היצרן או משתמש הקצה.
התחזות: מישהו מעמיד פנים שהוא אדם אחר כדי להשיג את אמונו של משתמש קצה או את אישורו של יצרן. חללים סלולריים – ובמידה רחבה יותר, חללי צרכנים – דורשים אבטחה רבה יותר כדי להגן על נתונים רגישים כאשר סמארטפונים, מחשבי טבלט ומכשירים חכמים אחרים צוברים פופולריות, ולפלחי הרכב והתעשייה יש צרכי הגנה דומים. בהמשך מפורטים רק חלק מהגורמים היוצרים חששות חדשים של אבטחה בכל הפלחים:
התרבות של מוצרי קצה אלחוטיים: במעבר מעולם מחווט לעולם אלחוטי, האפשרות של מתקפות זדוניות המורידות תוכנות חדשות – שמשנות את הכוונה המקורית של היצרן – הופכת לקלה יותר. כמו כן, רשתות אלחוטיות מבטלות את הצורך בגישה פיזית כדי להתחיל במתקפה. הפורץ יכול לתקוף בקלות ומרחוק כל מערכת מבלי להיות קרוב באופן פיזי למוצר הקצה.
יכולת תכנות בשטח: בשילוב עם מערכות הפעלה עשירות הדורשות קיבולת זיכרון גדולה, זיכרון הבזק (Flash) חיצוני הופך לדרישת חובה כדי לאפשר גם הוספה וגם שדרוג של שירותים חדשים. שדרוגים המבוצעים על ידי יצרנים חייבים להיות כלולים בתהליך ומתודולוגית מוגדרים כדי להבטיח את שלמות התוכנית החדשה. תהליך זה ומתודולוגיה זו חייבים לדחות גם קודים של כל תוכנה זדונית.
אימוץ של מודלים עסקיים חדשים: הפלח הסלולרי הראה כיצד יישומי תוכנה חדשים ניתנים לפריסה במהירות בפתרונות מערכת רבים. בהתאם להתפתחות זו, פלח כלי הרכב יכול להשתמש במודל הסלולרי כדי להקל על אימוץ של שירותים ויישומים להורדה בדור הבא של כלי רכב. דגם בתשלום מראש של הורדת סרטים, מוזיקה ושירותים אחרים צריך לאבטח עסקאות כספיות מבלי להוסיף עוד סיכון למערכת רכב קריטיות.
הגנה על מידע אישי: משתמשי קצה סלולריים יכולים להבין בקלות את הבעיה של פורצים הנכנסים למוצרי צריכה אלחוטיים כדי להשיג מידע אישי כגון לוחות שנה, אנשי קשר, נתונים ביומטריים ומידע רגיש אחר. זוהי בעיה חמורה למשפחה בודדת, אך יש לה השפעה מערכתית מינימלית. עם זאת, כשמדובר בקניין רוחני תאגידי, אנשים רבים בהרבה עלולים להיפגע ממתקפה זדונית כזו. גניבת רעיונות, פטנטים או מידע עסקי סודי כגון פעילות של מיזוג או רכש עלולה לגרום לנזק הולך ומתפשט ויש להגן עליהם בהקפדה רבה.
הגדרות ומידע בהתאמה אישית: אף שאולי יהיה קשה ליישם זאת, מגמה אחת היא להתאים אישית מוצרי קצה. משתמשי קצה יכולים להתאים אישית את ממשק המשתמש ואפליקציות ספציפיות בסמארטפון. על ידי שימוש בקוד מאובטח, הסמארטפון יכול לאחר מכן לעבור אתחול עם כל פרטי הפרופיל הספציפי עבור כל משתמש. ניתן להשתמש בקונספט זה גם בכלי רכב, כאשר למכונית יהיה מושב, הגה ומיקומי מראות שונים ובנוסף גם פרטי ניווט ומערכת מידע-בידור שונים בהתאם לפרופיל הנהג. הטכנולוגיה של ימינו מאפשרת זיהוי של הנהג הודות לנתונים ביומטריים. עם זאת, פורץ יכול להחליף פרופילים בין אנשים או לשנות פרופילים אם המערכת לקריאת הנתונים הביומטריים אינה מאובטחת. כתוצאה מכך, קונספט זה של התאמה אישית דורש זיהוי מאובטח של משתמש הקצה.
תשתית מחוברת יותר ויותר: כדי לשפר את היעילות והבטיחות, ממשלות מפתחות תשתית “מחוברת” בין מספר פונקציות, לרבות בטיחות ציבורית, ניהול חשמל ושירותים רפואיים ומוניציפליים. התוצאות של פריצה או מניפולציה במערכות אלה נעות מבעייתיות ועד לפוטנציאל לאסון. לדוגמה, שינוי לרעה של רשתות חשמל נע משימוש לא חוקי בחשמל ועד להפסקת חשמל מלאה באזור או במדינה. כדי למנוע מפורצים שינוי של תוכן המידע
השירותים, פתרונות טכניים חייבים לציית למושגים הבסיסיים הבאים:
שלמות: כדי להבטיח למקבל המידע שאיש לא שינה את התוכן.
אימות: כדי להבטיח שמקור המידע הוא השולח הצפוי.
סודיות: כדי להגן על מידע פעיל באמצעות מנגנון הסתרה.
אי-דחייה: כדי להבטיח שהשולח לא יוכל להכחיש שהמידע נשלח.
חשוב לציין שמערכת אבטחה לעולם לא תוכל להיות מאובטחת במאת האחוזים. רמת האבטחה חייבת להתאים לזמן ולכסף שפורץ מוכן להשקיע בפריצה למכשיר. מתכנן המכשיר חייב לפתור משוואה פשוטה זו: מערכת הופכת למאובטחת כאשר הזמן והכסף הדרושים לפריצה למכשיר עולים על היתרון המתקבל מהפריצה למוצר.
הטמעה טכנית נדרשת כדי לאבטח מערכת קצה
אתחול מאובטח
זיכרון הבזק (Flash) משמש להטבעה במעבד הראשי, ומאפשר שלמות ואימות בקלות של הקוד. בזכות אימוץ עשיר של מערכות הפעלה, זיכרונות הבזק חיצוניים הם כעת דרישה. מצב זה הופך את הקריאות והכתיבות של קוד היצרן לנקודת חולשה של המערכת כולה. המנגנון המוסבר בהמשך מייצג נתיב מאובטח כדי להבטיח שהקוד השוכן בזיכרון ההבזק תואם לקוד המוטבע במהלך שלב הייצור. מצב זה ממלא קריטריונים הכרחיים של שלמות ואימות. כדי לשמור על האבטחה של הפונקציות העיקריות במוצר הקצה, היצרן חייב להבטיח שפורץ זדוני לא יוכל לשנות את הקוד. כמו כן, במקרה של שדרוגי תוכנה, היצרן חייב להבטיח שאיש לא יוכל לגשת למערכת במהלך הורדות הקוד החדש. רובד נוסף של אבטחה במהלך תהליך האתחול מורכב מפענוח הקוד שהורד מזיכרון ההבזק החיצוני.
א. תשתית נדרשת
כדי להבין את המושג הכולל של שלמות ואימות, אמון הופך לקריטריון הראשון בין צדדים שונים המעורבים בתהליך החתימה. הבסיס למושג זה מתחיל באמון מלא ברשות האישורים.
רשות האישורים (CA-Certificate Authority): ישות זו מחזיקה בבעלות על מפתח ברמה העליונה (מפתחות CA) המשמשים ליצירת SA Cert, Mfg ואישור חתימת קוד. האישורים השונים מהווים הוכחה שכל הצדדים יכולים לתת אמון זה בזה. מפתחות שורש על (-Super Root Keys SRK) יכולים ליצור מפתח לחתימת קוד. רשות האישורים מייצגת את הישות המהימנה שצדדים אחרים המעורבים בתהליך זה חייבים לסמוך עליה במהלך תהליך החלפת האישורים כדי לטפל בפשטות בתהליך האימות.
רשות חתימות ( – Signature Authority): ישות זו יוצרת את החתימה של מוצר התוכנה של היצרן. רשות החתימות שומרת על המפתח הפרטי של חתימת הקוד ויכולה לייצר את המפתח הציבורי של חתימת הקוד שבו לקוח יכול להשתמש לצורך האתחול המאובטח. רשות החתימות חייבת לסמוך על רשות האישורים שתשיג את אישור ה-SA לצורך אימות היצרן. רשות האישורים ורשות החתימות צריכות להיות אותה חברה.
יצרן: הבעלים של רישיון התוכנה. היצרן חייב לסמוך על רשות האישורים שתספק את ה-IP לרשות החתימות.
אף עסקה לא יכולה להתחיל לפני שרשות האישורים מספקת את האישור הדרוש לצדדים האחרים. תהליך החתימה מתרחש כדלהלן:
1. SA חייבת להוכיח את אמינותה לצדדים אחרים
א. SA שולחת ל-CA את מפתח SA הציבורי שלה
ב. CA יוצרת את אישור SA על ידי חתימה על מפתח SA הציבורי באמצעות המפתח הפרטי של CA
ג. לאחר מכן SA מפרסמת את אישורי ה-SA שלה באופן ציבורי
2. היצרן חייב להוכיח את נאמנותו לצדדים האחרים
א. היצרן יכול ליצור מפתח יצרן ולשלוח את החלק הציבורי ל-CA
ב. CA חותמת על מפתח היצרן כדי ליצור את אישור היצרן באמצעות מפתח CA הפרטי שלה
ג. היצרן יכול לפרס את אישור היצרן באופן ציבורי
לאחר שהתהליך מתחיל, SA יכולה לאמת את אישור היצרן הודות לאישור ה-CA, והיצרן יכול גם הוא לאמת את אישור ה-SA.
ב. יזימת תהליך חתימת הקוד
לאחר שבוצעו בדיקות נאמנות הדדיות, השלב הבא מורכב מיצירת המפתחות לחתימת הקוד בין ה-SA והיצרן. שוב, תהליך זה מסתמך על CA. המפתחות לחתימת הקוד תלויים ב-SRK. יצירה זו של מפתח לחתימת קוד היא באחריות ה-CA. באופן ספציפי, CA יוצרת את זוגות ה-SRK הציבוריים והפרטיים וחותמת על מפתחות ה-SRK הציבוריים באמצעות מפתח CA (המפתח המאובטח ביותר). לאחר שתהליך ההכרה מבוצע, ה-SA יכולה ליצור מפתחות לחתימת קוד ולשלוח את המפתח הציבורי אל CA. ה-CA חותמת על המפתחות, פעולה שיוצרת אישורים לחתימת קוד שנשלחים חזרה אל SA ולאחר מכן מועברים ליצרן.
הערה: תהליך הכרה זה דומה למה שקורה כאשר לקוח בנק מעוניין לגשת לחשבון הבנק שלו. יש צורך להשיג אישור מצד שלישי שהמשתמש סומך עליו (CA) ואילו הבנק (SA) חייב לאמת את זהותו של המחזיק בחשבון. בתחילה, המשתמש הוכר ל-CA באמצעות סיסמה ושם משתמש. כאשר גישה מתבצעת, הבנק מבקש את שם המשתמש והסיסמה האלה, ואילו גם המשתמש חייב לוודא שדף האינטרנט הוא זה שנוצר על ידי הבנק ולא על ידי פורץ. במקרה זה, המפתח הציבורי הוא השם של משתמש הבנק ואלו המפתח הפרטי הוא פרטי החשבון.
ג. תהליך חתימת קוד
לאחר שהתהליך של נאמנות הדדית וחתימת קוד הסתיים, חתימת הקוד במוצר של SA יכולה להתחיל. קישור חומרה מאובטח בין היצרן ו-SA כבר הותקן. היצרן נכנס לסביבת SA באמצעות חשבון המוגן בסיסמה (כדי להוכיח ל-SA שהמשתמש הוא מי שהוא טוען שהוא וניתן להשוות אותו לאישור ה-CA). לאחר שנוצרת קורלציה בין שתי פיסות המידע, ה-SA יכולה לקבל את הקוד באמצעות תהליך העלאה. תרשים 2 מסביר את תהליך ה-Hash. Hash הוא פונקציה של מיפוי קבוצות נתונים גדולות בקבוצות נתונים קטנות שנקראות מפתחות.
תוכנת המוצר עוברת Hash באמצעות SHA-1 או SHA-256 כדי להשיג מילה בגרסת 160 סיביות (עבור SHA-1) וגרסת 256 סיבות (עבור SHA-256). החתימה נוצרת באמצעות האלגוריתם של ריבסט-שמיר-אדלמן (RSA) כאשר המפתח הפרטי לחתימת הקוד של היצרן משולב בתוצאת ה-hash. חתימה זו חוזרת ליצרן באמצעות הקישור המאובטח. יחד עם תוכנת המוצר, שני רכיבים אלה מורדים לזיכרון הבזק חיצוני.
ד. מחשוב מובנה (On-Board)
באמצעות אותו תהליך המשמש במהלך השגת החתימה, תוכנת המוצר המוטבעת בזיכרון ההבזק עוברת Hash כדי להשיג תוצאה מוצפנת הנקראת R1. מצד שני, החתימה המוטבעת השוכנת בזיכרון ההבזק תעבור RSA באמצעות המפתח הציבורי לחתימת קוד הממוקם במוצר הקצה. לאחר מכן מחושבת תוצאת R2. מפתח ציבורי זה מזווג למפתח הציבורי המאוחסן באופן סודי, כלומר של-R1 ול R2 חייב להיות קשר מתמטי (R1 חייב להיות שווה ל-R2). אם הם שווים, פירוש הדבר שהקוד השוכן בזיכרון ההבזק המוטבע לא השתנה ומתאים לקוד הראשי הורד במהלך שלב הייצור. אם הם שונים, פירוש הדבר שתוכנת המוצר עברה שינוי וחובה לעצור את האתחול כדי לשקף שינוי לא רצוי זה.
ה. הגנה נדרשת להבטחת אתחול מאובטח בטוח
יש להגדיר מספר אמצעי זהירות עבור הקונספט שהוסבר לעיל.
ה.1 הגנה על מפתח ציבורי לחתימת קוד
אם פורץ יוכל לשנות את המפתח הפרטי-ציבורי, ניתן יהיה להוריד תוכנת מוצר חדשה באמצעות החתימה החדשה שעברה hash עם המפתח הפרטי של הפורץ. לאחר מכן מוצר הקצה יוכל לעבור אתחול ולהחיל את אותו תהליך השוואה על מפתח מזווג חדש המקושר לתוכנת המוצר הזדונית. מנגנון האתחול המאובטח לא יכול לזהות את שדרוג התוכנה החדש מכיוון שההשוואה הוחלה באמצעות המפתח הציבורי שזווג למפתח הפרטי של הפורץ. מכאן משתמע שהמפתח הציבורי חייב להיות מוגן היטב כדי להימנע ממתקפות כאלה. זו הסיבה שמפתחות ציבוריים ממוקמים ב-ROM או ב-OTP, בהתאם לקיזוז של גמישות מול מקום.
ה.2 אבטחה באתחול מאובטח
היצרן חייב להבטיח שאין ניסיון לגשת למוצר במהלך שלב האתחול במטרה לשנות את הרצף או כדי לעקוף היבטי אבטחה של התוכנה המאומתת. הטמעה מבוססת ROM בשבב יכולה לעזור במניעת מצב זה. לסיכום, שלמות ואימות ממריצות את תהליך האתחול, שיש לו תפקיד חשוב במערכת. האתחול המאובטח מייצג הטמעה מורכבת כדי למלא את דרישות בעלות ה-IP, דרישות העצמאות והדרישות הפיננסיות של היצרן. הוא כולל את האמינות והאמון של ה-CA, שמהווים בסיס ברור לקונספט זה במשולב עם ההגנה על נכסים כגון מפתחות. ללא אמון זה, תהליך האתחול המאובטח יכול להיכשל בקלות, ולסכן מודלים עסקיים, פיננסיים וטכניים שלמים. הקורא יכול להבין בקלות את החשיבות של אתחול מאובטח בהצלחה של חברה.
השוואה בין רכיב תוכנה מובנה ובין החתימה המוטבעת מתבצעת במהלך רצף האתחול
קריפטוגרפיה
טכניקה זו בת 2000 שנה שימשה את יוליוס קיסר כדי לספק לצבאו הוראות שהאויב לא יוכל לקרוא. אף שגם הציוויליזציה וגם טכניקות הקריפטוגרפיה התפתחו עם הזמן, המטרה נותרה תמיד ללא שינוי: להפוך נתונים רגישים למעורפלים בפני משתמשים לא מורשים. הקונספט היסודי הוא שמירה בטוחה על מפתח שרק אנשים מועטים יודעים אותו כדי להצפין או לפענח את המסר. שתי הטכניקות היום הן קריפטוגרפיה סימטרית וקריפטוגרפיה אסימטרית.
א. קריפטוגרפיה סימטרית של מפתחות
קריפטוגרפיה סימטרית משמשת להצפנת נתונים ולשלמות נתונים בזכות הביצועים המעולים שלה. החלפת קבצים גדולים מתאפשרת בזכות קונספט זה. עם זאת, פענוח המסר מצריך קבלה בטוחה ומאובטחת של המפתחות. היסודות של קונספט זה מבוססים על דרכים לשליחת המפתחות ומניעת מתקפה מאדם לא מורשה. אם אדם לא מורשה זה מסוגל להשיג את המפתחות בדרכים זדוניות, המסר המוצפן ניתן לקריאה בקלות. אלגוריתמים סימטריים ידועים כוללים את AES, DES ו-3DES.
ב. קריפטוגרפיה אסימטרית של מפתחות
קונספט זה מסתמך על מפתחות הקשורים באופן מתמטי כאשר מסר אחד המוצפן באמצעות מפתח אחד ניתן לפענוח אך ורק באמצעות המפתחות האחרים. מפתחות פרטיים וציבוריים מייצגים את זוגות המפתחות האלה, שהוזכרו קודם לכן. חובה להגן על המפתח הפרטי והוא מסופק רק לאנשים מהימנים, ואילו את המפתח הציבורי ניתן לפרוס בשטח. קריפטוגרפיה אסימטרית ניתנת לשימוש במסרים קצרים עם מנגנוני פענוח איטיים. מסיבה זו קריפטוגרפיה אסימטרית נמצאת בשימוש נפוץ בהחלפת מפתחות,
בהשבעה (attestation) ובאימות. אלגוריתמים אסימטריים ידועים כוללים את RSA ,DSA ו-ECDSA.
בדיקת שלמות של זמן ריצה
לאחר שכל שלבי האתחול הושלמו ומערכת הפעלה עשירה ואפליקציות פועלות בפלטפורמה, תוכנה זו הופכת לפגיעה בפני מתקפות זמן ריצה. לדוגמה, תוקף יכול לנסות לשנות את ליבת מערכת ההפעלה כדי לשנות את התנהגות ההפעלה של המערכת. הדבר מתאפשר מכיוון שהמתקפה מתרחשת בזמן ריצה, לאחר שהאתחול המאובטח אימת את מערכת ההפעלה. בדיקת שלמות של זמן ריצה (RTIC- Run-time integrity checking) יכולה להגן מפני מתקפות כאלה ומתרחשת בשני שלבים. ראשית, מחושב hash קריפטוגרפי להתייחסות במהלך האתחול המאובטח כחלק מתהליך האימות. Hash זה של התייחסות מאוחסן לאחר מכן. בשלב השני, רכיבי Hash קריפטוגרפים תקופתיים מחושבים באותה תוכנה שאומתה במהלך שלב האתחול המאובטח. רכיבי ה-Hash המחושבים מושווים ל-Hash ההתייחסות המאוחסן. כל הבדל בין שני ערכי ה-Hash מציין שהתוכנה השתנתה לאחר האימות. הגנה על מידע מאובטח וחתימת הצפנה על הקוד מרמזות על אימות הקוד. עם זאת, כל זה לא מונע מפורץ לגשת לקוד השוכן בזיכרון ההבזק החיצוני. יש לנקוט מספר אמצעי זהירות והגנות כדי למנוע משכפול והנדסה לאחור. שכפול מאפשר לפורץ לשכפל מוצר, מה שיכול לגרום ליצרן החוקי לאבד נתח שוק מסוים אם קו מוצרים מלא של יצרן משוכפל. כתוצאה מכך, הצפנה של הקוד מבטיחה שהיצרן יכול להגן על הקניין הרוחני והרווחים שלו. ההצפנה דורשת שמפתחות מאובטחים ומוגנים יאוחסנו במוצר הקצה, ועדיף בזיכרון המעבד המוגן, עם מדיניות מתאימה של גישה. המפתח להצפנת הקוד ותמונת התוכנה ניתנים להורדה במהלך שלב הייצור באופן מאובטח שהיצרן חייב להגן עליו (נקרא הקצאה). במהלך שלב האתחול, חייב להתרחש פענוח כדי שהמערכת תתחיל לפעול. שלב הפענוח מופעל באופן מתחלף כדי לא לעכב את התוכנית וכדי למנוע הוספת עיכובים בין זיכרון ההבזק החיצוני וקריאה בתוך ה-RAM. הפענוח משתמש במפתח ההצפנה הממוקם בסביבה המאובטחת.
הפרדת משימות
הפרדת משימות היא קריטית במערכת מאובטחת כיוון שהיא מונעת ממשימות מהימנות להפריע למשימות אחרות. אספקת יחידת ניהול זיכרון (MMU) יכולה לאכוף בקלות הגבלות כאלה.
זיהוי ייחודי
הגנה על הקניין הרוחני של מוצר הקצה הופכת לדרישה מעניינת והכרחית מיצרני מוצרים. אחד מהשלבים הראשונים מורכב מזיהוי ייחודי של כל מוצר, שאותו ניתן לתכנת על ידי צריבת נתיך חשמלי.
מנגנון לזיהוי טיפול לרעה
המטרה של המנגנון לזיהוי טיפול לרעה היא לספק ראיות לכל ניסיון פיזי להסיר את מכסה המכשיר. המנגנון המוטבע הספציפי שואף לאיפוס הנתונים הרגישים המאוחסנים בזיכרון המוטבע. מידע זה יכול להיות מפתח סודי או כל נתון אישי אחר. פלחי שוק ספציפיים כגון תשלומים וחברות פיננסיות דורשים הטמעה מפורטת ומדויקת כאשר נקודות הטיפול לרעה חייבות למלא דרישות ספציפיות של תעשיית כרטיסי התשלום בנוגע לאבטחת עסקאות עם קוד זיהוי אישי (PCI PTS).
מאיץ יוצר מספרים אקראיים
גוש זה מספק נתונים אקראיים הנוצרים על ידי קביעת רישומי משמרות באמצעות שעונים הנגזרים ממתנדי טבעות. המספרים האקראיים שנוצרים על ידי יוצר המספרים האקראיים מיועדים לשימוש ישיר כמפתחות סודיים, סודות לפני מסרים, אתגרים אקראיים וכמויות דומות אחרות המשמשות באלגוריתמים קריפטוגרפים.
שלב איתור באגים מאובטח
ההזדמנות הבאה לפצח את הקוד היא על ידי קריאת ה-RAM בשבב שבו הקוד מוצג בטקסט רגיל. יציאת ה-JTAG מייצגת את הקישור לגישה ל-RAM. אף שהגנה על ה-JTAG דורשת הטמעה ספציפית, היציאה חייבת להישאר נגישה בשל סיבות שונות:
הבאה טכנית
ייצור, בדיקה ופתרון בעיות
איתור באגים לא באתר כדי לשדרג את התוכנה או כדי לבצע פעולות תחזוקה. מצבי אבטחה שונים מספקים רמה מסוימת של גמישות שבה המתכנת יכול לאפשר:
ללא איתור באגים: מספק את האבטחה המרבית למכשיר. כל תכונות ה-JTAG הרגישות לאבטחה נחסמות לצמיתות.
JTAG מאובטח: אבטחה גבוהה. השימוש ב-JTAG נמצא בפיקוח של מנגנון אימות המבוססת על אתגר-תגובה.
JTAG מופעל: אבטחה נמוכה. יצירת JTAG מופעלת תמיד.
ללא אבטחה. המכשיר במצב מאובטח נאלץ להמשיך במצב המאובטח במהלך פעולת JTAG.
סיכום
עם הצמיחה העצומה במכשירים המחוברים לרשתות, הצורך בהבטחת אבטחה ממערכות מוטבעות גדל במידה משמעותית. מערכות רשת, מערכות גישה ומערכות מוטבעות תעשייתיות הן תעשיות של מיליארדי דולרים, וההשפעה הכלכלית של חוסר הזמינות של מערכות מוטבעות אלה (או אם הן לא זמינות בפועל עקב מחסור באמון בפעולתן) תהיה גדולה פי כמה וכמה. קוד מקור פתוח נחשב יותר ויותר למודולים להורדה ונדחף לחורים בהצעות התוכנה העצמיות של יצרני ציוד מקורי (OEM), למרות המקורות הלא ידועים וללא ניתוח מעמיק של פרצות.
המומחיות והידע בתחום האבטחה
ש-i.MX פיתחה, בפלח הצרכנים, ניתנים לפריסה ולמינוף בפלחי הרכב והתעשייה. הטכנולוגיה של i.MX מספקת פתרונות אבטחה מובילים בעולם שלנו, שהוא יותר ויותר מחובר.
משפחת מעבדי QorIQ של Freescale תוכננה בכוונה עם מערכות משנה מהימנות במכשיריה, שמאפשרים למשתמשים לעמוד ביעדי מחשוב מובטחים מבלי להתפשר על דרישות הביצועים של המשימה. ארכיטקטורת האמון של
פלטפורמת QorIQ, הזמינה ב-P1010 P2040, P2041, P3041, P4040, P4080 P5010 ו-P5020, מספקת ליצרני ציוד מקורי את הנקודות לעיגון חומרה הדרושות להן כדי לפתח מערכת בעלת אמון. תמיכת חומרה נוספת במהלך זמן האתחול מבטיחה שקוד האתחול וזמן הריצה יהיה בעל אמון לפני הביצוע ומונעת גישת איתור באגים לא מורשת למצב המאובטח. התכונות של ארכיטקטורת אמון ואתחול מאובטח בתוך מעבדי QorIQ מספק ליצרן הציוד המקורי את הכלים הנחוצים להשגת מחושב מובטח במסגרת דרישות המערכת של גודל, משקל ועוצמה.
