אבטחה היא כעת דרישה מרכזית עבור מערכות מוטמעות. הרצון לחבר התקנים לאינטרנט כדי להקל על השליטה בהם ולמשוך נתונים בזמן אמת מהחיישנים שלהם מביא לסיכון גבוה לפריצה. בנוסף לסיכון להתקנים בודדים, פעולות הפריצה מסכנות רשתות שלמות.
הכיוון ברור: הספקים אינם יכולים לצאת לשוק ללא אבטחת מוצרי ה-IoT (האינטרנט של הדברים) לפי תכנון. הבעיה עבור יצרני ההתקנים כשהם מבקשים לרתום את העוצמה של ה-IoT עבור המערכות שלהם היא מורכבות ההטמעה של מנגנוני אבטחה רלוונטיים ויעילים. ניתן להבחין בקלות בצורך הבסיסי לאימות והצפנה של מערכות אלה. אך קשה הרבה יותר להצליח בהטמעה.
ישנם מספר מרכיבים, הן תוכנות והן חומרה, הנחוצים על מנת ליצור בסיס מאובטח למערכת מוטמעות. חולשה בכל אחד מהם עלולה להוביל בקלות לשימוש לרעה בחומרה, להעלאה של תוכנות זדוניות המשמשות כדי לתקוף את הרשת של המפעיל או לדליפת נתונים רגישים אל עברייני רשת. במקביל, צוותי עיצוב רבים מתמודדים לראשונה עם קשיי הפיתוח שנובעים מחששות בטיחות.
אחת מדרישות הליבה של אבטחה יעילה הוא שלכל התקן בו נעשה שימוש צריכה להיות זהות ייחודית משלו. פגם משותף שמנוצל על ידי האקרים הוא לגרום להתקנים לספק סיסמה נפוצה או פרטי כניסה נפוצים לשימוש של מהנדסי שירות ותחזוקה. פרטי כניסה אלה הם לעתים קרובות קלים לניחוש וגם אם לא בדרך כלל להאקרים קל להשיג אותם. עם פרטי כניסה אלו, ניתן לקבל גישה לא רק למכשיר אחד אלא אל הצי כולו. עברייני רשת היו יכולים ליצור צבאות בוטים של מחשבים זהים שיצרו התקפות מניעת שירות באמצעות שימוש פשוט בסקריפטים אוטומטיים. קובצי הסקריפט הזדהו והתחברו לכל התקן של מכל סוג שהיה מחובר לאינטרנט.
בעזרת מזהה ייחודי, ניתן להעניק לתת לכל מערכת אישורי אבטחה משלה ולצמצם באופן משמעותי את האפשרות של האקרים לבנות בוטים בקלות. רק אם למשתמש מורשה יש את האישורים הנכונים להתקן מסוים, תהיה לו אפשרות גישה. עם זאת, לרמת הגנה מוגברת זו יש השלכות על התכנון, הפיתוח, תהליכי הניהול השירות.
הטמעת אבטחה יעילה באופן שמקל על הפיתוח ולא ומשבש אותו כרוך בבחירות זהירות. הבחירה הראשונה היא בנוגע ליסודות החומרה המופעלים על מנת להגן על שלמות התקן היעד. תשתית זו מבטיחה בנוסף להבטחת חסימת הגישה לקושחת הליבה של ההתקן עבור מי שאין לו אישור, גם להבטחה שלא ניתן יהיה להטריד את הפונקציות שלו ולהשתמש בהתקן כדי לתקוף את הרשת. לדוגמה, אם האקר השיג אישורי גישה להתקן אחד, צריך שיהיה בלתי אפשרי להמיר אותם לאחרים כדי לקבל את אותם האישורים על מנת ליצור בוט למשל. כתוצאה מכך, זהות ויושרה קשורים באופן אינטימי.
תשתית המפתח הציבורית – (PKI) מספקת אמצעים להקמת ואספקה של מזהה ייחודי ומהימן לא רק בתוך ההתקן עצמו אלא עבור כל הרשת. PKI מסתמך על הרעיון של קריפטוגרפיה א-סימטרית, טכניקה שמקשרת שני מפתחות מספריים יחד באופן מתמטי. הראשון הוא המפתח הציבורי, אשר משמש בדרך כלל כדי לאמת הודעות. כפי שנרמז משמו, מפתח זה ניתן להפצה רחבה מבלי להתפשר על הבטיחות. הוא מספק דרך קלה עבור כל אחד כדי לשלוח הודעות מאובטחות להתקן, רק כל עוד הוא יודע באיזה במפתח ציבורי יש להשתמש. ההתקן עצמו זקוק למפתח הפרטי המאפשר לחתום על הודעות שנשלחו אליו, שיאומתו על ידי המפתח הציבורי המתאים.
מהפעולות הבסיסיות של PKI ניתן לבנות מודלים מובנים יותר לאימות, כגון אישורים דיגיטליים המדגימים את זהותו של התקן. כדי ליצור אישור דיגיטלי, התקן חותם על הודעה או מאתגר יצירה של חתימה באמצעות המפתח הפרטי. מפתח ציבורי תואם נמצא בשימוש של הנמען כדי לקבוע את תוקף החתימה.
מובן מאליו שהמפתח הפרטי זקוק להגנה חזקה. לא מספיק רק לתכנת מפתח לזיכרון בלתי הפיך בהתקן לפני שהוא נפרס מכיוון שהוא נגיש בקלות. לעולם אין לחשוף את פרטי המפתח הפרטי. אם פרטי המפתח נחשפים, האקרים יכולים לבנות התקנים משובטים משלהם. לאחר מכן הם מסוגלים להתחזות להתקן האמיתי ולסכן את האבטחה של יישומי רשת אשר תלויים בנתונים שנשלחו על ידי ההתקן.
הבעיה היא שבתכנון של מיקרו-בקר רגיל כל תוכנה קריפטוגרפית הפועלת על ליבת המעבד זקוקה לגישה למפתח הפרטי על מנת לבצע את החישובים הדרושים בהנחה שהמפתח נמצא בבקר. דרישת הליבה לחומרה היא אפוא אלמנט מאובטח המשמש לקיפול פעולות קריפטוגרפיות אלה לחלק עצמאי של חומרה מוגנת יחד עם אחסון מאובטח למפתחות הפרטיים. בתור פונקציות המפתח והקריפטוגרפיה המאוחסנות יחד בתוך אותו גבול פיזי מאובטח, אין צורך לשלוח נתונים רגישים דרך הערוץ הפנימי של המערכת.
איור 1 – רכיב מאובטח הוא כספת המגנה על סודות, הוא התקן נלווה למיקרו-בקר
במקום זאת, כאשר המערכת צריכה לתקשר בצורה מאובטחת או להוכיח את זהותה, היא קוראת לגורם המאובטח להיענות לאתגר אקראי. התגובה לאתגר זה היא קוד הנגזר בצורה אריתמטית מהחלק האקראי של האתגר והמפתח הפרטי הרלוונטי המאוחסן בתוך האלמנט המאובטח. במילים אחרות, אתגר אקראי חתום בידי מפתח פרטי. באופן זה, האלמנט המאובטח יכול להוכיח שהוא שומר על הסוד המתאים אך אינו נדרש לחשוף את המפתח הפרטי הרגיש עצמו.
האלמנט המאובטח יכול גם להגן על המכשיר מפני קוד מזויף שתוקף עשוי לנסות להפעיל ולהשתמש בו כדי לנסות ולפגוע במערכת. מנגנון ההגנה הדרוש כדי למנוע זאת הוא אימות הקוד, המכונה לעתים גם אתחול מאובטח או אימות קוד לפי זמן ריצה. במקרה זה, האתגר שנשלח לגורם המאובטח הוא חתימה המתקבלת מתמונת האתחול החתומה המאוחסנת בהתקן. כל עדכונים לקוד חייבים להיות חתומים על ידי היצרן המקורי בידי אמצעות המפתח הפרטי שלו. באמצעות נהלי אימות אתחול ותצורת זמן ריצה מאובטחים, המערכת יכולה לתמוך בעדכונים המסופקים על ידי היצרן ללא סיכון להרצת עדכונים שסופקו על ידי צד שלישי באמצעות מתקפת אדם אמצעי או גישה דומה.
מקש זה המשמש לאימות חתימת הקוד הנו אישור רגיש ומשום כך אמור לשהות באזור זיכרון מוגן ובלתי ניתן לשינוי. אם ניתן לשנות את המפתח, המערכת פשוט לא תפעל. אם ניתן לשנות את צמד המפתחות, ניתן להתמודד עם הקוד באופן דומה.
דוגמה להגנה יעילה ניתן למצוא בטכנולוגיית Microchip ATECC608A. זהו אלמנט מאובטח בו ניתן להשתמש בכל מערכת מבוססת מיקרו-בקרים בזכות השימוש בו בקישור תקשורת I²C או בקישור תקשורת עם כבל יחיד. ההתקן משלב זיכרון לא נדיף עם כמה מאיצי קריפטו שנועדו לתמוך באלגוריתמים המבוססים על אלגוריתמים בעקומה אליפטית, למשל, בסיליקון מאובטח. ההתקן מעולם לא חושף מפתחות פרטיים דרך קישור התקשורת וכולל מספר תכונות חומרה נגד התנגשות, שהופכות התוכן שלו לבלתי ניתן לגילוי למעשה.
למרות שאלמנט מאובטח המשודך למיקרו-בקר מספק בסיס יעיל לבניית התקנים מוטמעים מחוברים שיכולים להבטיח אבטחה גבוהה, שילוב זה הוא רק חלק מהפתרון הכולל. ישנם מקרי רבים הכרוכים בשימוש בבניית פרוטוקולים מורכבים בתוכנות מוטמעות מתוך פונקציות הליבה שהאלמנט המאובטח מספק. לדוגמה, בנוסף לאתחול מאובטח, התקן IoT יהיה חייב להיות מסוגל לתקשר עם מארחים מרוחקים באמצעות פרוטוקולים מוצפנים כגון TLS ולייצר אישורים לפי דרישה המראים כי המכשיר לא נפגע כאשר הוא מעוניין להתחבר לשירות חדש. כאשר היצרן או מפעיל השירות רוצים לשלוח עדכון קוד, יהיה צורך לאמת את חתימת הקושחה טרם עדכון זיכרון ההבזק וההפעלה מחדש של המערכת.
דרישה נוספת עשויה להיות היכולת לזהות מערכת או אביזרים או מחסניות מתכלות ולקבוע אם הם אותנטיים. ניתן לבצע פונקציה זו באמצעות פרוטוקולים הדומים לאלה המשמשים לבניית דוגמת אימות הקוד, אך עם כמה הבדלים מרכזיים. לדוגמא, לכל ציוד היקפי יכול להיות רכיב מאובטח משלו המשמש לבדיקה שמערכת המארח שאליה הוא מחובר היא עצמה אותנטית.
למרות שהעקרונות העומדים מאחורי כל אחד מהפרוטוקולים המיישמים פונקציות אלה הם פשוטים למדי, ההטמעה עשויה להיות מסובכת מכיוון שהיכולת לבצע ניפוי בעיות מוגבלת מהצורך של המערכת לציית לפרוטוקולים המאובטחים.
הנחה נפוצה במהלך הפיתוח היא שלחיצה על כפתור האיפוס או שטיפת תוכן הזיכרון תאפשר למהנדסים לקבל גישה למכשיר שאינו מגיב. מצבי ניפוי באגים מעניקים למפתח בדרך כלל גישה מיוחדת למערכת. אך כאשר מציגים רמות אבטחה גבוהות יותר הנדרשות למערכות שיחוברו לאינטרנט, חלק מההנחות הללו אינן חלות עוד. כישלון ביישום תוכנה בצורה הנכונה עלול להוביל לכך שהתקן האב-טיפוס יהפוך לבלתי ניתן להשגה. החלקים הבעייתיים ביותר בפיתוח מערכות מאובטחות טמונים בניפוי של פרוטוקולי הליבה. לדוגמה, קל להכניס באגים לקוד המשמש לעיבוד קודי סיסמה או תעודת אבטחה הגורמים לכך שההתקן לא יהיה מסוגל להגיב לבקשות תקפות. אם ניתן היה לאפס את המכשיר כדי לקבל גישה, המתקן היה מספק להאקרים דלת אחורית למערכת, אותה ניתן לנצל בקלות. כתוצאה מכך, פיתוח ממוקד אבטחה מציג מכשולים בפני תהליך הפיתוח. קשה להתמודד איתם אם לצוות אין ניסיון בטכניקות הנדרשות.
עם זאת, אחד מהיתרונות של של מערכות הבנויות על תשתית PKI הוא שניתן לבנות יישומים על גבי פרוטוקולי ליבה ומקרי שימוש, כגון אימות של הפעלות חתומות ויצירת אישורים, בהם ניתן להשתמש מחדש בפרויקטים רבים. תובנה כזו סייעה להוביל ליצירת פלטפורמת Trust מבית Microchip. פלטפורמה זו מספקת חבילת תצורות, קוד מקור, כלי חומרה ותוכנה שנועדו להקל על הלקוחות להטמיע מגוון רחב של מקרי שימוש בתהליך עבודה שמנחה את המשתמש מהרעיון ועד והטמעה על בסיס חומרה הכוללת אלמנט מאובטח כגון ATECC608A.
פלטפורמת Trust מחולקת לשלוש הצעות עיקריות. הפשוטה ביותר היא Trust&GO, המספקת מערכת קבועה של פונקציות, כגון הענקת גישה עבור התקנים לשירותי ענן המתארחים ב-AWS, Google Cloud, Microsoft Azure או ענן פרטי. תצורה נוספת הנתמכת על ידי Trust&GO היא פתרון אימות מאובטח מלא עבור התקנים הנדרשים להתחברלרשת אלחוטית LoRaWAN.
TrustFLEXמספקת רמה נוספת של התאמה אישית עם תמיכה במגוון רחב של פעולות, החל מאתחול מאובטח ועד לייצור אישורים. האפשרות השלישית, TrustCUSTOM , מספקת ללקוחות את היכולת לכוונן יצירה ושילוב של אלמנטים מאובטחים במודל האבטחה הרצוי שלהם.
איור 2 – זרימת הפיתוח עם פלטפורמת Trust מבית Microchip
אלמנט חשוב בפלטפורמת Trust שמקל על הגישה לאבטחה בהשוואה להצעות אחרות הוא האופן בו ניתן לפרוס את שירות אספקת המפתח המאובטח ביישומים בעלי נפח נמוך. עם שרשרות אספקה מתחרות בעלות רכיבים מאובטחים, כמות ההזמנה המינימלית יכולה להיות 100,000 בגלל התקורה הכרוכה בהגדרת האישורים והמפתחות הראשוניים שיש לתכנת לחומרה בקו הייצור המאובטח של הספק. עם Trust&GO, לקוחות יכולים לרכוש אלמנטים מאובטחים החל מ-10 יחידות להזמנה ולקבל את כל התמיכה של תשתית פלטפורמת Trust , כולל הפרשה. עבור TrustFLEX, כמות ההזמנה המינימלית היא נמוכה, עד 2,000 יחידות הכוללות גם אספקה, אך עדיין מספקת למשתמש רמה גבוהה יותר של שליטה על אישורים, מפתחות ויישומים שלהם ניתן לצפות מפתרונות מותאמים אישית לשרשרת אספקה.
תחת פלטפורמת Trust מבית Microchip, ללקוחות יש גישה אל מנגנוני אבטחה הניתנים להתאמה אישית עם סיכוני פיתוח ופריסה נמוכים בהרבה מאשר אצל פתרונות קיימים. השילוב של כלים, קוד מקור ותשתית אספקה מספקים למפתחי מערכות משובצות אמצעי לקבלת גישה למערכת מלאה ומאובטחת הפועלת מהרעיון ועד לפריסה, ומפחיתה את תהליך הפיתוח מחודשים לימים.
איור 3 – זרימת ההזמנה/מסירה של פלטפורמת Trust מבית Microchip
