טווח האיום על אבטחת הסייבר התרחב באופן דרמטי בכל פלחי השוק עם הגעתו של האינטרנט של הדברים (IoT). כל מכשיר עם IoT שנוסף לרשת מציג נקודה חדשה לתקיפה, לא רק של המכשירים עצמם אלא גם של המערכות, המקומיות וגם של ענן, שמשמשים לניהולם.
להתקפות יכולות להיות השלכות חמורות מכיוון שפעולת החדירה מוצלחת למכשיר IoT מאפשרת לטעון אליו קושחה חדשה כך שניתן יהיה להשתמש בה באופן זדוני. למרות שחלק מהמתקפות עשויות רק לשבש את פעולת המכשיר כדי שניתן יהיה להשתמש בו בדרך חדשה, למשל כצומת ב-botnet שמשמש לביצוע התקפות מניעת שירות, אחרים עשויים להשתמש במערכת שנפגעה כדי לפלוש לשירות – הרשת של המפעיל.
החדירה הופכת לקלה יותר באמצעות אישורי תוכנה בלבד, כגון סיסמאות. באמצעות האישורים הבסיסיים הללו, האקר שתוקף מכשיר בהצלחה יוכל להשתמש במידע הזה כדי לקבל גישה לשירותים מרוחקים, ואולי לתקוף אותם ביתר קלות. אבטחה שמופעלת באמצעות חומרה יחד עם זהות מאובטחת מספקת מנגנון למניעת ניצול המכשירים והופכת אותם לחשופים פחות למתקפות ראשוניות מוצלחות.
עם אבטחה שמופעלת באמצעות חומרה, ניתן ליצור זהות תקפה וקודי גישה למכשיר רק במהלך הייצור באמצעות מנגנוני תשתית של מפתח ציבורי (PKI). תחת PKI, לכל מכשיר יש מפתח פרטי ייחודי שקשור מתמטית לאישור דיגיטלי ידוע שנשמר באופן מאובטח על ידי היצרן. מפתח פרטי זה משמש עבור חתימת אתגר לזיהוי המכשיר באופן ייחודי בכל שרת שיש לו גישה למפתח הציבורי המתאים. המפתח הציבורי הוא סט מידע גלוי לציבור ולכן אינו מהווה סיכון אם הוא מופץ למשתמשים לא מורשים. בהקשר של מכשיר IoT, זהות המכשיר מודגמת באמצעות השימוש במפתח פרטי. המפתח הציבורי המשויך משמש לפרוטוקולים שקובעים כי הזהות הנתבעת תקפה. זהות זו יכולה לשמש לאורך כל מחזור חיי המכשיר כדי לאמת את כל עדכוני הקושחה שעשויים להיות מיושמים וכן את זהות המכשיר בעת גישה לשירותים מרוחקים.
לנוכח תפקידם המרכזי בכל מערכת קריפטה כלשהי, המפתחות הפרטיים של המכשיר אינם יכולים להיות חשופים להתקפות פיזיות או לחילוץ מרחוק. באופן אידיאלי, המפתחות הקריפטוגרפיים מוחזקים באלמנט מאובטח שמציב גבול מבודד ומאובטח כך שהמפתחות לעולם לא ייחשפו. זוהי אינה משימה של מה בכך. התכנון דורש הגנה מפני חבלה והגנה ומפני התקפות ציתות כגון ניתוח ערוצים צדדיים. הגנה מספקת על המפתח בדרך זו דורשת מומחיות אבטחה ברמה גבוהה. היא מאריכה בנוסף את זמן הפיתוח של פתרון ה-IoT. אך לא ניתן לשכוח כי האחריות על המפתח היא פרקטיקה ביטחונית חשובה ביותר ליישום. למרבה המזל, עבור יצרני האלמנטים המאובטחים, ישנם מוצרים שזמינים ברמות ההגנה הנדרשות, כגוןMicrochip Technology ATECC608.
איור 1: האלמנט המאובטח בפלטפורמת Trust של Microchip מאחסן סודות כולל מפתחות ואישורים שנוצרים במהלך הייצור בתוך המפעלים המאובטחים של החברה, ולעולם אינם נחשפים לאורך כל תהליך האספקה המאובטח שלו.
למרות שקיימים רכיבים כאלה, נותרו בעיות שימוש בניהול זהויות שמופעל על ידי חומרה. לרוב היצרנים, משלבי מערכות ונותני שירות לא היה קל להשיג את הצורך להחיל את הזהות המאובטחת באופן שלא יעמיד אותה בסכנה מתוקף בעל משאבים טובים. הגישה המקובלת היא להגדיר אלמנט מאובטח בחומרה במהלך הייצור עם המפתחות הפרטיים המתאימים. עם זאת, שיקולי לוגיסטיקה בשרשרת האספקה הגבילו בדרך כלל את השימוש בגישה זו לפריסות גדולות. אספקה של כל מכשיר עם זהות מאובטחת פירושה התאמה אישית של תהליך הייצור: מאמץ יקר אלא אם ההתאמה האישית מופחתת בנפח יחידות גבוה כך שהעלות לכל מכשיר תושפע באופן מינימלי.
עם זאת, כעת ניתן לספק את התצורה הנדרשת של רכיב מאובטח בצורה חסכונית גם בכמות הזמנה מינימלית (MOQ) נמוכה (עד עשר) באמצעות הגדרת תצורה מראש והקצאתם מראש למכשירי IoT. באמצעות דגם זה שנתמך על ידי פלטפורמת Trust של Microchip, אפילו מצלמת מעקב בסיסית, שער, מזגן או אפליקציית IoT דומה יכולים להיות מוגנים באמצעות אישורים גנריים שהופקו מראש ונעולים בתוך אלמנט מאובטח עבור אימות כניסה עצמאי לענן. העלות הכוללת למכשיר עבור מסירת אחסון המפתחות המאובטח מבוסס חומרה זה עם אישור גנרי נמוכה מזו שיכולים ספקי שירותי PKI ורשויות אישורים מצד שלישי להציע, והגישה מפחיתה משמעותית את המורכבות ואת זמן היציאה לשוק.
הצבת פתרון
מכיוון שיש כעת לנפח נמוך עד בינוני גישה לדרך חסכונית להכנסת ניהול זהויות מאובטח במכשירים שלהם, השלב הבא הוא הגדרת האלמנט המאובטח בצורה המתאימה ביותר למקרי השימוש שלהם. הסיבה לכך היא שיש לספק למכשיר אישורים ונכסי הצפנה אחרים שמשמשים למודל האימות הנתון. כמו זהות הליבה של המכשיר, יתכנו מפתחות פרטיים וסודות נוספים שיש להטמיע באלמנט החומרה. לדוגמא, ייתכן שלא יהיה צורך במפתח הבסיס כדי לאמת אביזרים, ציוד היקפי, תוכן של צד שלישי ומארחים מרוחקים, כך שניתן יהיה לנהל את האישורים בנפרד.
העיקרון שעומד מאחורי האלמנט המאובטח הוא שהוא שולט בגישה למשאבים חיוניים ופועל כבדיקה נגד פעילות לא מורשית, כגון ניסיונות להחליף את הקושחה שאושרה על ידי היצרן בקוד זדוני שעשוי לנסות להשתמש במידע הסודי שהמכשיר מחזיק כדי לבצע עוד מתקפות.
דרישה מרכזית להבטחה שתוקפים לא יוכלו לחדור ולתכנת מכשיר מחדש היא שימוש באסטרטגיית אתחול מאובטח שמוגנת על ידי אלמנט מאובטח. אתחול מאובטח מבטיח שמכשיר ה-IoT יוכל להריץ קוד מורשה בלבד. בתנאי אתחול מאובטח, המכשיר יכול לטעון רק חסימות קוד שגובשו ונחתמו באמצעות מפתח פרטי בבעלות היצרן.
כאשר על המיקרו-בקר צריך קוד מאתחול ה-ROM, המיקרו-בקר מבקש אימות מהמפתח הציבורי האמיתי שאיננו ניתן לשינוי בידי האלמנט המאובטח. רק אם אימות זה יעבור, MCU ינסה לטעון את הקוד. אם המכשיר נתקל בבלוק קוד שנחתם בצורה שגויה, הוא יפסיק לטעון את התוכנה שנפגעה וינסה לחזור למצב הגדרות היצרן או, אם ישבית את עצמו אם לא יצליח. כל עוד לא ניתן לשנות את קוד האתחול של MCU, באמצעות הצבתו ב-ROM או בהבזק מוגן, לא ניתן לעקוף את פונקציית הבדיקה עצמה.
כשאבטחת הליבה מוצבת, ניתן להוסיף בקלות מקרי שימוש אחרים, כגון תמיכה באימות על בסיס אישור משרתים מרוחקים, רכיב מרכזי במכשירי IoT. האימות מרחוק הזה עושה שימוש בפרוטוקולים סטנדרטיים כגון Transport Layer Security (TLS) עבור תקשורת מוצפנת ו-X.509, שמשמש לניהול אישורים דיגיטליים שמוכיחים כי המכשיר או השירות הם מקוריים.
על פי תקן X.509, כל האישורים הדיגיטליים מתייחסים לתעודת OEMJ בסיסית באמצעות היררכיה של אישורי ילדים. המידע המועבר על ידי האישורים מספק אמצעי לזיהוי הבעלים הלגיטימי של כל אישור וממנו לקבל את המפתח הציבורי של האישור בהמשך ההיררכיה, כך שניתן יהיה לאמת את חתימת האישור התלוי.
כאשר התקן IoT שמאובטח כראוי מתקשר עם שרת מרוחק, הוא עושה שימוש במידע שבאישורים שהוא מחזיק כדי להוכיח שהוא משתמש תקף בשירות. לעומת זאת, השרת עושה שימוש במערכת האישורים שלו כדי לאשר בפני המכשיר שגם הוא אמיתי. כל עוד המכשיר מחזיק באישורים הנדרשים, ניתן להבטיח אימות דו כיווני.
בהקשר של ה-IoT, ניתן להשתמש באישורים דיגיטליים כדי לפשט את התהליך של חיבור המכשירים למערכת כאשר הם מופעלים לראשונה ולנסות להתחבר לספק השירות שלהם דרך האינטרנט. ניתן להשיג זאת באמצעות העברת האישורים הדרושים לשרתים כשהאלמנט המאובטח מתוכנת לראשונה וכן באמצעות שמירת האישורים שבהם המכשיר יעשה שימוש כדי לאמת את אותם שרתים באלמנט לצד המפתח הפרטי המרכזי של המכשיר. כדוגמה לגישה זו, Microchip עבדה עם תכונות שירותי האינטרנט של אמזון (AWS) כדי לאפשר לכל המוצרים שנוצרו באמצעות פלטפורמת Trust לעלות באופן זה לשירותי IWS של AWS. תמיכה בפרוטוקולים סטנדרטיים ובמערכות אישורים פירושה שניתן להשתמש באותן טכניקות בקלות בשירותי ענן אחרים, כגון Microsoft Azure, וכן בתשתיות ענן פרטיות והיברידיות.
מקרה שימוש מרכזי נוסף עבור ה-IoT הוא זה של עדכוני קושחה מהאוויר (OTA) עבור מכשירי IoT. עדכונים אלה מספקים את האפשרות לתקן פגיעות אבטחה מבלי לחשוף את המכשירים לפגיעה מתהליך העדכון עצמו. ניתן לבדוק עדכונים חתומים דיגיטלית שנשלחו באוויר בצורה דומה לקוד שאימותו נבדק במהלך האתחול המאובטח לפני שניתן להחיל את העדכון. הקוד שנשמר יצטרך לעבור בנוסף בדיקות אתחול מאובטח כאשר המכשיר יופעל מחדש.
מקרי שימוש נוספים כוללים הגנה על IP, כדי לבדוק את תקפותם של חלפים ואביזרים אופציונליים, וכן הגנה על נתוני משתמשים, סיבוב מקשים ואימות LoRaWAN™. יצרנים מסוימים עשויים להזדקק לאפשרויות שניתנות להתאמה אישית וחורגות משירותי הליבה הללו. אחרים עשויים להזדקק לגישה עילית נמוכה יותר לאבטחה אם הם מספקים מכשירי IoT בעל משאבים מוגבלים. הרשאת הליבה של Google Cloud IoT, למשל, אינה דורשת יצירת אישורים דיגיטליים מלאים. השירות שמפעיל את ‘JSON web tokens’ (JWT), שמקורם במפתח פרטי של הליבה שמוחזק בתוך ה-ATECC608B מחליף את מקומה של הכניסה הרגילה מבוססת סיסמה.
הגמישות לטפל במקרי שימוש מגוונים אלה בעלויות התקנה נמוכות מתאפשרת באמצעות פלטפורמת Microchip Trust ותמיכתה במספר דגמי התקשרות שונים. המודל הראשון מספק ללקוחות דרך קלה להשגת מכשירים עם אישורים מאובטחים, באמצעות זרימת ברירת מחדל. במודל זה, המפתח הפרטי של האישור המאובטח והאישורים הגנריים נוצרים במהלך הייצור במתקן מאובטח של Microchip. המפתח והתעודות נותרים ללא חשיפה לאורך כל תהליך האספקה המאובטח, נעולים בתוך האלמנט המאובטח בו הם נשארים בטוחים במהלך המשלוח. את האישורים הציבוריים הקשורים ניתן להעביר לשירותי החיבור לענן או לשרת הצטרפות לרשת LoRaWAN.
איור 2: התהליך להגדרת אספקת מפתח מותאם אישית לאחר תהליך האב טיפוס והקוד, ההקצאה מתחילה בטקס מפתח ויצירת סודות. לאחר סיום בדיקת האב-טיפוס, הסוד נעול באלמנט המאובטח
היות ויצרנים רבים רוצים אפשרות לרמת גמישות גבוהה יותר באימות ויש להם את האפשרות ליצור ולהזריק אישורים על סמך שרשרת האימות שלהם, מודל מעורבות שני מספק קבוצה של מקרי שימוש מוגדרים מראש שמעניקים את היכולת לבצע את הפעולות האלה באופן אוטומטי. שינויים נרחבים יותר אפשריים במודל ההתקשרות השלישי. בגישה זו, המוצגת באיור 2, הלקוח מתחיל בהזמנה עבור מכשיר אלמנט מאובטח ריק ואז משתמש בכלים שמסופקים על ידי שבבים שבונים את שלבי האספקה, כולל ה-XML שמשמש לבקרת מסירת מפתחות ואישורים פרטיים לאלמנט המאובטח במתקנים המאובטחים של Microchip.
לסיכום, הודות להתפתחויות האחרונות בכלים ורכיבים מקוונים לאבטחה מבוססת חומרה, חברות בכל גודל פרויקט יכולות להטמיע כעת אלמנט מאובטח במכשירי ה-IoT שלהן. המחסומים שהקשו על היקף התצורה והאספקה של אלמנטים מאובטחים הוסרו. התהליך הביא להפיכתה של שרשרת אספקה מאובטחת למיינסטרים, דבר שמאפשר להרחיב את מודלי האבטחה המומלצים ביותר בכל המערכת האקולוגית של ה-IoT.
