אבטחת BLE באפליקציה: החוליה שרוב המוצרים משאירים חשופה

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

ממה בכלל מתגוננים

  • האזנה (Sniffing). תעבורת BLE לא מוצפנת ניתנת ליירוט עם ציוד זול — כולל נתוני בריאות, פקודות ומזהים.
  • אדם-בתווך (MITM). תוקף שמתייצב בין האפליקציה למוצר ומעביר תעבורה דרכו, תוך יכולת לשנות אותה.
  • התחזות (Spoofing). מכשיר עוין שמתחזה למוצר שלכם ומפתה את האפליקציה להתחבר אליו — או אפליקציה עוינת שמתחברת למוצר.
  • שידור חוזר (Replay). הקלטת פקודה לגיטימית — למשל "פתח מנעול" — ושידורה מחדש מאוחר יותר.

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

ל-BLE יש מנגנוני צימוד (Pairing) מובנים, וההבדל ביניהם דרמטי. צימוד Just Works — הנפוץ במוצרים בלי מסך וכפתורים — מצפין את הערוץ אך אינו מגן מפני MITM, כי אין אימות של הצד השני. Passkey ו-Numeric Comparison מוסיפים אימות דרך קוד שהמשתמש מאשר, ו-LE Secure Connections מבסס את החלפת המפתחות על קריפטוגרפיה חזקה. הכלל המעשי: במוצר רגיש — מנעול, מוצר רפואי, מוצר תשלומים — אסור להסתפק ב-Just Works לבדו; צריך שכבת אימות נוספת. איך משלבים את הצימוד בחוויית משתמש חלקה — במאמר על צימוד מוצר לאפליקציה.

שכבת אבטחה אפליקטיבית: לא לסמוך על הערוץ בלבד

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

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

אבטחת החיבור טובה רק כמו הקושחה שמאחוריו. תכנון שירותי GATT נכון — הרשאות קריאה/כתיבה מינימליות לכל Characteristic — מתואר במאמר על פיתוח BLE בקושחה. חשוב לא פחות: הגנה על הקושחה עצמה באמצעות Secure Boot והצפנת קושחה, וחתימה על כל עדכון שמגיע דרך האפליקציה — כפי שמוסבר במאמר על עדכון קושחה מהאפליקציה (DFU). ערוץ DFU לא חתום הוא הדרך הקלה ביותר להשתלט על מוצר.

רשימת ביקורת מעשית לפני שחרור

  • אין Characteristic כתיב פתוח. כל נקודת כתיבה בפרופיל ה-GATT דורשת הצפנה ואימות — כולל נקודות "דיבוג" שנשכחו מהפיתוח.
  • מפתח ייחודי לכל יחידה. מפתח גלובלי שנצרב בכל המוצרים זהה פירושו שפריצה אחת פורצת את כל הצי.
  • נעילת ממשקי דיבוג. UART ו-SWD פתוחים על הלוח עוקפים כל אבטחת תקשורת.
  • בדיקת חדירה בסיסית. סריקה עם כלי BLE סטנדרטיים לפני ייצור מגלה את הפרצות המביכות בעלות נמוכה.

פרטיות והרשאות: גם זה חלק מהאבטחה

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

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

רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.