מה באמת עובר באוויר? Wi-SUN, מהמדידה ועד הרשת המאובטחת

אפשר לבנות שני מעגלים שמשדרים זה לזה מספר, ועדיין להיות רחוקים מאוד מרשת שאפשר לפרוס בעיר. רשת צריכה לצרף מכשירים חדשים, להחליף מסלול כשקישור נופל, להגן על התקשורת ולשמור על הבנה משותפת בין מוצרים של יצרנים שונים. Wi-SUN נועד להסדיר את העבודה הזאת. הוא אינו רק שיטת שידור, והחלק המעניין בו נמצא דווקא בחיבור בין הרדיו, הניתוב והאבטחה.

מהו FAN, ומה הוא מחייב?

FAN הוא קיצור של Field Area Network, כלומר רשת תקשורת של התקנים הפרוסים בשטח. בעולם Wi-SUN זהו שם של פרופיל תקשורת: מפרט שבוחר מנגנונים מתוך תקנים קיימים ומגדיר כיצד להשתמש בהם יחד. אפשר לחשוב עליו כעל חוזה בין המכשירים. לא מספיק ששני רכיבים מסוגלים לשדר באותו תדר; הם צריכים להסכים גם על צורת ההודעה, ההצטרפות, בחירת המסלול והגנת הנתונים.

הפרופיל אינו ממציא את כל התקשורת מאפס. הוא משתמש במשפחת תקני הרדיו 802.15.4 של ארגון מהנדסי החשמל והאלקטרוניקה, IEEE, ומעליה בפרוטוקול האינטרנט: כללים לכתובות ולהעברת חבילות מידע. הגרסה שבה משתמש FAN נקראת IPv6, כלומר Internet Protocol version 6. כאן המילה ״אינטרנט״ מתארת שפה של רשת, לא חובה להתחבר לענן. אפשר לבנות מערכת סגורה שבה כל המונים מדברים עם שרת מקומי.

מה שמחייב בפועל הוא המפרט הטכני של גרסת הפרופיל והתפקיד שבוחרים למוצר. נתב, שער והתקן סוללה אינם נדרשים לבצע בדיוק אותה עבודה, ולא כל אפשרות רדיו חייבת להיות ממומשת בכל רכיב. בהסמכה היצרן מצהיר אילו יכולות מימש, ונבדק מול הדרישות הרלוונטיות. המפרט המלא ותכנית הבדיקות העדכנית נמצאים במסלול החברים של הארגון; לכן אין כאן טענה שקראנו את כל סעיפי החובה של FAN 1.1.

אפשר בכל זאת לראות היטב את ההבדל בין חובה לאפשרות. בטופס התאימות הפומבי של מימוש FAN ותיק מסומנים IPv6 ופרוטוקול הודעות קצרות בשם UDP כחובה, בעוד פרוטוקול הזרם TCP מסומן כאפשרות. בהמשך מופיעות דרישות שתלויות בתפקיד המכשיר. זו דוגמה לכך שהמילה ״תומך״ אינה מספיקה לבחירת מוצר; צריך לדעת במה הוא תומך ובאיזו תצורה. את ההשלכה המדויקת לגרסה חדשה בודקים במסמכי ההסמכה שלה, ולא מעתיקים מהטופס הישן.

ההבחנה החשובה ביותר היא בין הובלת המידע לבין משמעותו. FAN מסדיר כיצד להעביר חבילות ברשת, אבל אינו קובע לכל מוצר מהו ״ליטר״, איך נראית פקודת סגירת ברז ומה משמעות בית מספר ארבע במדידה. שני מכשירים יכולים להיות תואמי רשת ועדיין לא להבין את נתוני היישום זה של זה. לשם כך צריך גם הסכם תוכנה מעל הרשת: מבנה הודעות משותף, יחידות מידה והתנהגות מוסכמת. זה בדיוק הגבול שבין רשת שעובדת לבין מוצר שעובד.

מי מחובר למי?

במרכז רשת השטח נמצא נתב גבול, Border Router. השם מתאר את תפקידו: הוא מחבר בין רשת הרדיו לבין רשת אחרת, למשל רשת קווית של מרכז בקרה. הוא אינו חייב לפרש את מדידת המים כדי להעביר אותה; הוא יכול לנתב חבילת IPv6 לשרת שמבין את היישום. כמובן, עדיין צריך להגדיר כתובות, מסלולים והרשאות גישה משני צדדיו. חיבור מבוסס IP אינו מבטל את עבודת האינטגרציה הזאת.

בין המונים לשער נמצאים נתבים שמעבירים גם הודעות של אחרים. הם שייכים לקבוצת המכשירים בעלי התפקיד המלא, Full Function Node, או FFN. הנתב שומר מידע על שכנים ועל מסלולים, מקשיב לרדיו ומחליט למי להעביר את החבילה הבאה. ריבוי הקישורים האפשריים יוצר רשת אריג, Mesh: לא רק קו אחד קשיח בין כל מונה לשער. אבל קישור חלופי קיים רק אם בשטח באמת יש שכן מתאים שאפשר להגיע אליו.

מד המים שלנו יכול לקבל תפקיד מצומצם יותר: Limited Function Node, או LFN. זהו התקן קצה שמסתמך על נתב הורה ואינו מנתב תעבורה של מכשירים אחרים. הוא יכול לישון בין מועדי התקשורת שלו, ולכן אינו מספק לשכנים תשתית זמינה כל הזמן. FAN 1.1 מוסיף את המסלול הזה לרשת, אבל אינו הופך אוסף חיישני סוללה לרשת ממסרים שכולם ישנים. מישהו עדיין צריך לספק את הנתבים הערים.

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

מה קורה כשמד חדש נדלק?

המכשיר אינו מתחיל משליחת מדידות לכל מי ששומע. תחילה הוא מחפש פרסומי רשת ובוחר רשת מתאימה לפי ההגדרות והמידע שהוא מקבל. לאחר מכן מתבצע אימות זהות, נרכשות הגדרות הרשת ונבנית היכולת להעביר תעבורה. תיעוד Silicon Labs מציג את השלבים האלה בנפרד: בחירת רשת, אימות, קבלת תצורה, הגדרת ניתוב ולבסוף מצב תפעולי. ההפרדה חשובה גם לדיבוג: קליטת פרסום רשת אינה מוכיחה שהמכשיר עבר אימות או שיש לו מסלול לשרת.

גם התקן רחוק מהשער יכול להשתתף באימות. בדוגמאות TI, מכשירים שכבר נמצאים ברשת מעבירים את הודעות האימות של המצטרף לכיוון הגורם המאמת. זהו תפקיד מוגבל של העברת ההליך, לא מתן הרשאה מוקדמת לשלוח תעבורת יישום חופשית. התכנון פותר בעיה מעשית: אילו כל מונה היה צריך להגיע ישירות לשער כדי לקבל זהות, היתרון של רשת רב־קפיצית היה נפגע כבר בהתקנה.

איך בוחרים מסלול בלי מפה של כל העיר בכל מונה?

הנתבים משתמשים בפרוטוקול ניתוב שמיועד לרשתות חסכוניות שבהן הודעות עלולות ללכת לאיבוד. שמו RPL. במקום שכל נתב יכיר בהכרח כל נתיב אפשרי, הוא מחזיק שכנים שיכולים לקדם את החבילה לכיוון שורש הרשת, בדרך כלל נתב הגבול. השכנים מפרסמים מידע שמאפשר להעריך את איכות הדרך דרכם. לכן ״הורה״ הוא תפקיד במסלול, ולא רק המכשיר בעל עוצמת הקליטה הגבוהה ביותר.

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

גם הדרך חזרה דורשת מידע. במצב הניתוב המתואר בתיעוד FAN של TI, המידע על המבנה נאסף בשורש, והנתבים אינם שומרים כל אחד טבלה מלאה לכל יעדי הרשת. השורש יכול לכוון הודעה כלפי מטה באמצעות מידע מסלול המצורף לחבילה. כך מצמצמים את הזיכרון הנדרש בכל נתב, אך מוסיפים עבודה ומידע ניתוב במקומות אחרים. התקן LFN עצמו נשען על ההורה ואינו מנהל את מנגנון ניתוב הנתבים.

איך נפגשים באותו תדר?

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

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

עכשיו נבנה הודעה אמיתית: שמונה בתים של מד מים

נניח שאנחנו מתכננים את תוכנת מד המים, ובוחרים לשלוח קריאה מצטברת בליטרים. לצורך הכתבה נגדיר הודעה קצרה משלנו, לא פורמט שמוכתב על ידי Wi-SUN. בית הוא יחידה של שמונה ביטים; הטבלה הבאה מגדירה שמונה בתים בסך הכול. בחרנו שמספרים מרובי־בתים יישלחו מהבית המשמעותי ביותר לפחות משמעותי, ושהקריאה תהיה מספר שלם ללא סימן.

בכתיב הקסדצימלי, שבו כל זוג סימנים מייצג בית, ההודעה תהיה 01 01 00 2A 00 00 30 39. השרת חייב לדעת ש־30 39 בסוף המספר מייצג כאן חלק מהערך 12,345, ושהיחידה היא ליטר. המספר הסידורי יכול לסייע ליישום לזהות דיווח כפול; הוא אינו מנגנון אבטחה בפני עצמו. שדות נוספים, כמו זמן מדידה, מצב סוללה או טיפול בגלישת המונה, הם החלטות תכנון שלא הוספנו לדוגמה המצומצמת.

זו שכבת היישום: החלק שמבין מים, ברזים ומשמעות של מספרים. אפשר לבחור במקומה פורמט אחר, כולל טקסט או מבנה בינרי תקני. אפשר גם להשתמש בפרוטוקול בקשות ותשובות למכשירים מוגבלים במשאבים, CoAP, ששמו המלא Constrained Application Protocol. הוא נותן כללים לבקשות, תשובות ומעקב אחרי הודעות, אבל גם הוא אינו בוחר עבורנו את כל משמעות שדות המונה. דוגמת שמונת הבתים שלנו אינה משתמשת בו, כדי שאפשר יהיה לראות את המעטפות בנפרד.

מהמוצר אל הרשת: מי מוסיף איזו מעטפת?

כדי לשלוח את שמונת הבתים לתוכנה מסוימת בשרת, אפשר להשתמש ב־UDP, כלומר User Datagram Protocol. זהו פרוטוקול שמעביר הודעות נפרדות ומוסיף מספרי יציאות: מזהים שמאפשרים למחשב המקבל למסור את ההודעה לתהליך הנכון. כותרת UDP רגילה היא בת שמונה בתים ומכילה גם אורך ובדיקת תקינות. היא אינה מוסיפה אישור שהשרת עיבד את המדידה, ואינה משחזרת בעצמה הודעה שאבדה.

את הודעת UDP עוטפים בחבילת רשת שמגדירה לאן היא צריכה להגיע. כאן נכנסת IPv6: היא מוסיפה כתובות מקור ויעד, ולנתבים יש מידע שמאפשר לקדם את החבילה. כתובת IPv6 היא בת 128 ביט, אבל חשוב יותר להבין את תפקידה: היעד יכול להיות שרת שנמצא מעבר לשער, ולא רק השכן ששומע את השידור הבא. בכותרת יש גם מונה שמגביל את מספר מעברי הניתוב כדי שחבילה לא תסתובב לנצח.

כותרת IPv6 הבסיסית היא בת 40 בתים. לכן בדוגמה שלנו יש בשלב הזה 8 בתים של מדידה, 8 של UDP ו־40 של IPv6: יחד 56 בתים, לפני כותרות הרחבה, הגנת יישום ומסגרת רדיו. זה חשבון מבנה, לא אורך השידור בפועל. הוא גם מראה למה אין טעם להסתכל רק על שמונת הבתים שהחיישן יצר: מערכת התקשורת צריכה לשאת איתם כתובות והוראות.

כדי לא לשדר שוב ושוב מידע שאפשר לשחזר, משתמשים בשכבת התאמה בשם 6LoWPAN: העברת IPv6 ברשתות אלחוטיות חסכוניות. בין תפקידיה דחיסת כותרות. למשל, אם חלק מכתובת ידוע מתוך ההקשר, אפשר במצבים המתאימים לייצג אותו בקיצור ולשחזר אותו בצד השני. זו אינה דחיסה קסומה של כל המדידה, וגודל הכותרת הדחוסה אינו מספר קבוע; הוא תלוי בכתובות, בשדות ובהקשר הזמין.

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

לבסוף צריך למסור את המידע לשכן ברדיו. לצורך זה נוצרת מסגרת של שכבת הקישור, המכונה MAC — Medium Access Control, בקרת הגישה לערוץ. היא מכילה שדות בקרה וכתובות של הקישור המקומי, מידע רלוונטי לתזמון ולפרוטוקול, ונתוני אבטחה. בתוכה נישא המידע של השכבות שמעליה. לפניה מוסיף הרדיו מידע פיזי לזיהוי תחילת השידור ולפענוחו; פרטים כמו האורך והקידוד תלויים במצב הרדיו שנבחר.

אפשר לסכם את המסע בלי לבלבל בין המעטפות:

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

מה משתנה כשההודעה עוברת דרך פנס נוסף?

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

אישור מהשכן עדיין אינו אישור מהשרת. הודעת אישור ברמת הקישור יכולה לומר שפנס א׳ קיבל את המסגרת, אך אחר כך פנס ב׳ עלול לא להיות זמין, או שהשרת יכול לדחות את הנתונים. אם המוצר חייב לדעת שהקריאה נשמרה, צריך אישור ברמת היישום ומנגנון לטיפול בחזרות ובכפילויות. גם שימוש ב־TCP, פרוטוקול בקרת תמסורת שמספק זרם בתים אמין ומסודר, אינו אומר שהיישום השלים פעולה עסקית. בקרה על שסתום דורשת להבחין בין ״הפקודה הגיעה״ לבין ״השסתום אכן נסגר״.

גם לזהות יש כמה שכבות. כתובת הרדיו מזהה התקן בקישור, כתובת IPv6 מאפשרת להגיע אליו דרך הרשת, ותעודת האבטחה קושרת זהות למפתח. מספר המונה בחשבון הלקוח יכול להיות מזהה נוסף של היישום. בפרויקט צריך להגדיר את הקשר ביניהם, לא להניח שכולם אותו מספר. החלפת רכיב רדיו אינה אמורה ליצור בטעות לקוח חדש, וכתובת שמישהו טוען שהיא שלו אינה הוכחת זהות קריפטוגרפית.

חתימה, תעודה והצפנה: שלוש פעולות שונות

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

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

ב־Wi-SUN משתמשים בתעודות בפורמט X.509, פורמט תקני למסמכי זהות כאלה. תיעוד Silicon Labs מפרט תעודת התקן ייחודית עם שדות שמזהים את סוג החומרה ואת מספרה הסידורי, לצד המפתח הציבורי והגבלות השימוש בתעודה. בין ההגבלות מופיע גם זיהוי ייעודי לשימוש כהתקן Wi-SUN FAN. לכן אי אפשר לקחת סתם תעודה של אתר אינטרנט ולהניח שהיא תתאים למונה. פורמט ושדות לא מתאימים עלולים למנוע אימות גם כשיש בשבב מנוע הצפנה חזק.

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

ההליך שבו FAN משתמש נקרא EAP-TLS. החלק EAP הוא מסגרת ניתנת להרחבה לאימות, והחלק TLS הוא פרוטוקול לאימות ולהקמת תקשורת מוגנת. כאן משתמשים בשילוב כדי לבדוק את שני הצדדים: הרשת בודקת את המכשיר, והמכשיר בודק את צד האימות של הרשת. שרת האימות יכול להיות בתוך נתב הגבול או מאחוריו ברשת אחרת. מכאן גם נובע שחיבור כזה אינו רק ״סיסמה של השכונה״ שהועתקה לכל המונים.

רגע הכניסה: איך מונה זר הופך לחבר ברשת?

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

תהליך הכניסה בנוי, באופן מפושט, כך:

1. עוד לפני ההתקנה מכניסים למונה את זהותו הקריפטוגרפית ואת בסיס האמון שלו: על אילו גופים מאשרים הוא סומך. גם צד הרשת צריך להיות ערוך לבדוק ולהרשות את זהויות המכשירים.

2. המונה מגלה רשת ומתחיל הליך אימות. מכשירים שכבר מחוברים יכולים להעביר את הודעות ההליך אל נתב הגבול. אין צורך שמד מים בקצה הרחוב ישמע ישירות את שער הרשת כדי להזדהות.

3. מתבצע האימות ההדדי שתיארנו. המפתחות הפרטיים נשארים אצל בעליהם; התעודות וההוכחות הקריפטוגרפיות מאפשרות לבדוק את הצד שממול.

4. מתוצאת האימות נגזר בסיס למפתחות זוגיים, המיוחדים לקשר האבטחה בין המכשיר לנתב הגבול. באמצעות חילופי הודעות נוספים, המכונים ״לחיצת יד בת ארבעה שלבים״, מבססים את המפתחות ומוסרים למכשיר מפתחות קבוצתיים בצורה מוגנת.

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

זו המחשה של התפקידים, לא רשימת כל הודעות הפרוטוקול. בתיעוד TI נקרא בסיס המפתח הזוגי PMK, כלומר Pairwise Master Key; המפתח הזוגי הזמני נקרא PTK, או Pairwise Transient Key. מפתחות הקבוצה נקראים GTK, כלומר Group Transient Keys. השמות דומים, אבל הסמכות שלהם שונה: מפתח זוגי אינו מפתח קבוצתי, ותעודה אינה אף אחד מהם.

למה לא חותמים בחתימה דיגיטלית על כל מדידה?

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

מסגרות הרדיו מוגנות באמצעות מנגנון שמשלב הצפנה ותג אימות, המבוסס על צופן AES במצב CCM*. AES הוא צופן בלוקים תקני; כאן מצב ההפעלה מוסיף בדיקה קריפטוגרפית שהתוכן המוגן לא שונה בידי מי שאין לו המפתח. תג כזה אינו חתימה ציבורית ייחודית של המונה: גם צד אחר שמחזיק במפתח המשותף נמצא בתוך גבול האמון. ובדיקת שגיאות רגילה, כמו סכום ביקורת, חלשה עוד יותר מבחינה זו — היא מיועדת לזהות שיבוש, לא להוכיח זהות של שולח עוין.

לכן ״הרדיו מוצפן״ אינו שקול ל״רק המונה והשרת יכולים לקרוא״. נתבים המשתתפים בהגנת הקישור אינם בהכרח מחוץ לגבול האמון שלה, והקישור החיצוני אחרי השער דורש טיפול משלו. אם צריך להגן על המדידה גם מפני רכיבי תווך, אפשר להוסיף הגנה מקצה לקצה, למשל פרוטוקול אבטחה להודעות בשם DTLS — Datagram Transport Layer Security — בין ההתקן לשרת. זו שכבה נוספת עם מפתחות, זיכרון ותעבורה משלה, ולא תכונה שמתקבלת אוטומטית מעצם הסמכת FAN.

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

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

ומה אם המונה נגנב כשהוא עדיין מורשה?

כאן נחשף ההבדל בין ״יש הצפנה״ לבין מערכת שאפשר להפעיל לאורך שנים. מי שהעתיק רק תעודה ציבורית עדיין אינו מחזיק בזהות המלאה. אבל אם תוקף השתלט על מכשיר אמיתי ויכול להשתמש במפתחותיו, הוא פועל מתוך מעגל האמון. הוא אינו צריך לשבור את הצופן כדי לשלוח הודעות בשם אותו מכשיר. גם אי־אפשר להניח שמכשיר עוין יציית לפקודה שמבקשת ממנו למחוק את עצמו.

ב־Wi-SUN יש להבחין בין שלוש פעולות: חסימת הזהות כדי שלא תאומת שוב, ביטול המפתחות הזוגיים שכבר הוקמו, והחלפת מפתחות הקבוצה שנחשפו למכשיר. תיעוד נתב הגבול של Silicon Labs מציג פעולות נפרדות לביטול מפתחות זוגיים וקבוצתיים, ומבהיר שחסימה קבועה דורשת חסימת תעודת ההתקן אצל סמכות האימות. כלומר, ״מחקתי את המפתחות״ אינו בהכרח ״אסרתי כניסה מחדש״.

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

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

מה באמת חדש ב־FAN 1.1 מבחינת אבטחה?

לא נכון להציג תעודות או אימות הדדי כהמצאה של Wi-SUN ב־2026. הם חלק מהארכיטקטורה הוותיקה שלו. החידוש שרלוונטי למונה הסוללה הוא התאמת ניהול האבטחה למכשיר שיכול לישון רוב הזמן: ב־FAN 1.1 התקנים חסכוניים משתמשים בקבוצת מפתחות נפרדת, שחייה ארוכים יותר, וגם קשרי האבטחה שלהם עם נתב הגבול נשמרים למשך זמן ארוך יותר.

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

מה מכל זה קורה בזמן שהמונה ישן?

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

נחשב דוגמה שאינה תלויה במותג: סוללה של 2,000mAh, שמתוכה מקצים לתכנון 70%, נותנת 1,400mAh שימושיים במודל שלנו. עשר שנים דורשות זרם ממוצע של כ־16µA בצד הסוללה, כולל החיישן, העיבוד, הרדיו וממיר המתח. מקלט של 4.4mA שפועל לחמש אלפיות שנייה בכל שנייה מוסיף לבדו 22µA לממוצע. כבר חלון ההאזנה הזה חורג מהתקציב, עוד לפני שנשלחה מדידה אחת.

אם אותו חלון נפתח פעם בדקה, תרומתו היא כ־0.37µA, אבל אז זמינות הקליטה שונה. זהו תרגיל חשבוני, לא תזמון רשמי של Wi-SUN. הוא מראה כיצד דרישה כמו ״אני רוצה שהברז יקבל פקודה מיד״ הופכת לצריכת חשמל. על החישוב מוסיפים מדידות הצטרפות והתאוששות מתקלות, ולאחר מכן בודקים גם טמפרטורה, פריקה עצמית והזדקנות הסוללה. עשר שנות פעולה אינן נגזרות מנתון שינה אחד בדף רכיב.

עכשיו אפשר להבין מה היצרנים באמת מוכרים

רכיב משולב יכול להכיל גם מעבד שמריץ את היישום וגם רדיו שמבצע את השידור, אך ביניהם עובדת חבילת תוכנה גדולה: מחסנית התקשורת. היא מטפלת בשכבות שתיארנו, בתורים, בשכנים, בהצטרפות ובמפתחות. לכן ״הרדיו תומך ב־802.15.4״ אינו מוכיח שהמוצר כולל Wi-SUN FAN. צריך גם מחסנית מתאימה, משאבי זיכרון והסמכה לתצורה המסוימת.

Silicon Labs מציעה את FG28 עם מעבד Cortex-M33 במהירות עד 78MHz, עד מגה־בית של זיכרון תוכנה ועד 256 קילו־בית של זיכרון עבודה. מגה־הרץ כאן הוא קצב השעון של המעבד, לא קצב הרדיו. במצבי Wi-SUN הרכיב משתמש בשינויי תדר לייצוג המידע, שיטה שנקראת FSK, או Frequency Shift Keying. יש בו אפשרות להריץ גם את לוגיקת המוצר, אבל חלק מהזיכרון מוקדש לרשת עצמה. הדגם EFR32FG28A120F1024GM48 מוצג בכ־$5.18 בכמות אלף.

בדף FG28 מופיעים 4.4mA בקליטה בתנאי 920MHz ו־400 אלף ביט לשנייה, לעומת 2.8µA בשינה עמוקה עם שמירת 256 קילו־בית ושעון. שידור של ‎+20dBm בדגם המתאים מגיע ל־81.8mA בתנאי 915MHz המפורטים. אלה מצבי מדידה שונים, לא צריכת FAN ממוצעת. כדי ליהנות משינה צריך שהחומרה והתוכנה אכן יכניסו את המוצר אליה; מדריך LFN מציין במפורש מגבלות לפי רוויזיות לוח.

FG25 מוסיף אפשרות להעביר יותר מידע בזמן רדיו קצר. המעבד שלו מגיע ל־97.5MHz, עם עד 1920 קילו־בית של זיכרון תוכנה ו־512 קילו־בית של זיכרון עבודה. לצד FSK הוא תומך בחלוקת השידור בין תדרי־משנה, OFDM — Orthogonal Frequency Division Multiplexing — ובמצבי Wi-SUN של עד 2.4 מיליון ביט לשנייה. הדגם EFR32FG25B222F1920IM56 מוצג בכ־$9.78 לאלף. אבל הגדלת קצב הרדיו אינה מאיצה באותה מידה את כל מסלול ההודעה, שעדיין כולל המתנות, ניתוב והגנה.

ביצועי הרדיו שלו מדגימים את הפשרה. רגישות המקלט היא עוצמת האות החלש שהוא יכול לפענח בתנאי בדיקה מוגדרים, ונמדדת כאן ב־dBm, יחידה לוגריתמית להספק ביחס למיליוואט. לפי Silicon Labs, ב־2.4 מיליון ביט לשנייה הרגישות היא כ־‎−95.3dBm, ובמצב OFDM של 12.5 אלף ביט לשנייה כ־‎−116dBm. המצב האיטי יכול אפוא להתמודד עם אות חלש הרבה יותר; אין לשלב את הקצב המהיר עם רגישות המצב האיטי כאילו התקבלו יחד.

גם הזרם וההזנה משתנים עם המצב. בדף הנתונים של FG25 מופיעים 186mA בשידור OFDM מהיר ובעוצמת ‎+16dBm, ודרישת הזנה של 3.45–3.8V למגבר במצב OFDM. זה אינו אומר שכל הודעה מהירה צורכת יותר אנרגיה מהודעה איטית, משום שמשך השידור יכול להתקצר. זה כן אומר שצריך לתכנן את מקור המתח לפי הפולס, ולמדוד אנרגיה למסירה מוצלחת במקום להשוות רק זרמי שיא.

TI מציעה ב־CC1354P10 מעבד Cortex-M33 של 48MHz לצד בקר חישה עצמאי. בקר החישה מאפשר לבצע משימות מדידה מסוימות בלי להעיר את המעבד הראשי בכל אירוע, כך שחיסכון אינו תלוי רק ברדיו. לפי החברה, הקליטה צורכת 5.8mA ב־868MHz, ושידור ב־‎+20dBm ב־915MHz צורך 69mA. נתון ההמתנה של 0.98µA הוא מצב חומרה, לא הבטחה למוצר מחובר. במדריך ערכת התוכנה 8.33.00.16 שנבדק מופיע ש־LFN אינו נתמך; התאמה למוצר סוללה דורשת בדיקת גרסה ותפקיד ולא הסתמכות על אותו מספר המתנה.

Renesas מציעה גם רדיו נפרד, R9A06G062, שאפשר לשלב עם מעבד RX65N, וגם פתרון משולב בשם RX65W-A. האחרון כולל מעבד עד 120MHz, שני מגה־בית זיכרון תוכנה ו־640 קילו־בית זיכרון עבודה; הוא עדיין רכיב באריזת שבב, לא מודול אנטנה מוכן. במדריך שלו מפורטים, בין היתר, 16.7mA לקליטת FSK ב־100 אלף ביט לשנייה ו־21.5mA במצב OFDM המתואר. אלה נתוני חלק הרדיו, לא השוואה מבוקרת של מוצר שלם מול המתחרים. ההפרדה או השילוב עם המעבד משנים את הלוח ואת חלוקת התוכנה, אך לא פוטרים מבדיקת מחסנית FAN והסמכה.

מי שרוצה לחסוך חלק מתכנון הרדיו יכול לבחור מודול, למשל Digi XBee for Wi-SUN המבוסס על FG25. מודול הוא לוח קטן עם רכיב התקשורת, רכיבי העזר וקושחה, ולא רק שבב שיש להקיף במעגל משלנו. Digi מפרטת קצבים עד 2.4 מיליון ביט לשנייה, קליטה של 12.2mA ושידור OFDM של 195mA בתנאי ‎+18dBm. גם נתון הטווח ״עד שבעה קילומטרים״ מסויג בתנאי קו ראייה וסביבה; הוא אינו תחזית למונה בתוך בור.

במודול מופיעה מעטפת נוספת שקל לטעות בה: ההודעות שעוברות בין מעבד המוצר למודול על החוטים. Digi מגדירה עבורן מסגרות עם אורך, סוג פעולה ובדיקת תקינות. זהו ממשק מקומי שלה, לא פורמט Wi-SUN אוניברסלי שנשלח כפי שהוא באוויר. המעבד מוסר למודול נתונים ויעד; קושחת המודול בונה את מעטפות הרשת והרדיו. לכן לכידת החיבור הטורי ולכידת הרדיו מציגות מבנים שונים, אף שהן מתארות את אותה פעולת שליחה.

מה ההבדל מהמתחרים, עכשיו כשמבינים את השכבות?

LoRa היא שיטת שידור רדיו, ואילו LoRaWAN היא מערכת כללים לרשת המשתמשת בה. בפריסה הרגילה חיישן משדר לשערים שמעבירים את התעבורה לשרת רשת; החיישנים אינם בונים ביניהם את רשת נתבי ה־IPv6 שתיארנו. קיימת הרחבת ממסר תקנית, אבל היא אינה זהה למבנה הניתוב של FAN. ב־LoRaWAN Class A, מצב עבודה חסכוני, חלונות הקליטה נפתחים לאחר שידור מההתקן. הוא מתאים לדיווחים קטנים, במחיר זמינות מוגבלת לפקודות בין הדיווחים.

Zigbee אינו רק ״Wi-SUN בתדר אחר״. הוא כולל סביבת רשת ויישום משלו, ובמוצרים תואמים גם מוסכמות שמסייעות למכשירים להבין פעולות כמו תאורה ובקרה. Thread, לעומתו, הוא נקודת השוואה קרובה יותר כשמדברים על רשת IPv6 חסכונית; את משמעות פעולות הבית החכם אפשר להוסיף באמצעות Matter, שכבת יישום נפרדת. זו הסיבה שתאימות ברדיו, תאימות ברשת ותאימות בין מוצרים אינן אותה הבטחה.

וגם החלוקה לפי תדר אינה קבועה. בספטמבר 2026 נפתחה הסמכת Suzi, הרחבת Zigbee לתדרים נמוכים מ־1GHz. לכן אין להציג כל Zigbee כאילו הוא מוגבל תמיד ל־2.4GHz. אבל רדיו קיים שאינו מסוגל לעבוד בתחום החדש אינו מקבל את היכולת מעדכון תוכנה בלבד. השוואה עדכנית צריכה לבדוק פרופיל, חומרה, תוכנה ותדר אזורי, לא רק את שם המשפחה.

אבטחה מול המתחרים: ההבדל אינו רק מספר הביטים במפתח

כעת אפשר להשוות באותו סרגל: מה המכשיר יודע לפני ההתקנה, איך הוא מוכיח את זהותו, מי מקבל מפתחות לקריאת הנתונים, ומה עושים כשמישהו מאבד את האמון בו. אין הצדקה לתת ל־Wi-SUN ציון אבטחה גבוה אוטומטית מפני שמופיע בו TLS. צריך להשוות שכבות מקבילות, גרסאות ותצורת מוצר בפועל.

Zigbee: השינוי החשוב מתרחש לפני מסירת מפתח הרשת

ברשת Zigbee מרכזית פועל מנהל אמון, Trust Center, שמנהל את ההצטרפות והמפתחות. יש מפתח רשת משותף, ולצדו אפשר להשתמש במפתחות לקשרים מסוימים. במסלולי הצטרפות ותיקים ניתן להשתמש במפתח התחלתי מוכר; כשבאמצעותו נמסר מפתח הרשת, מאזין שמכיר אותו עלול ללמוד גם את הסוד החדש. אבל זו אינה גזירת גורל של כל Zigbee: קוד התקנה ייחודי למכשיר מאפשר בסיס אמון אחר, ותצורת מנהל האמון קובעת אילו מסלולים יתקבלו.

ב־Zigbee PRO 2023, המכונה גם רוויזיה R23, נוספה הקמה דינמית של מפתח לקשר לפני מסירת מפתח הרשת, כאשר שני הצדדים תומכים בכך. המנגנון משתמש בקריפטוגרפיה של מפתח ציבורי, ויכול להשתלב בקוד התקנה או בסוד אימות אחר. כך, מפתח המגן על ההצטרפות אינו חייב להיות קבוע ומוכר מראש. מנהל האמון יכול גם לבצע תשאול נוסף לפני שיאשר את ההתקן. זה שינוי ממוקד ברגע הרגיש של הכנסת חבר חדש, ולא רק שינוי בהצפנת הודעות רגילות.

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

Zigbee 4.0 הוכרז בנובמבר 2025 עם דגש נוסף על גמישות קריפטוגרפית: יכולת להתפתח ולהחליף מנגנונים לאורך זמן. ההודעה הציבורית אינה בסיס לקביעה שכל מוצר כבר מפעיל אלגוריתם מסוים, ובוודאי לא להכרזה על עמידות למחשוב קוונטי. יתרה מכך, גם במשפחת Zigbee היו שימושים בתעודות קודם לכן, למשל ב־Smart Energy. לכן ההבחנה ההוגנת היא מה מחייב הפרופיל שבחרנו, ולא ״ל־Wi-SUN יש תעודות ול־Zigbee אין״.

Thread: גם כאן נוספה הצטרפות המבוססת על תעודות

Thread הוא שכבת רשת, ולכן זו השוואה ישירה יותר ל־FAN מאשר Matter. ב־Thread 1.4 הוצג ב־2024 מסלול אופציונלי בשם TCAT, ראשי תיבות של Thread Commissioning over Authenticated TLS: צירוף התקן באמצעות חיבור מאומת בין ההתקן לכלי ההתקנה. שני הצדדים מציגים תעודות, ובגרסה המתוארת ההליך עובר על קישור Bluetooth חסכוני. היצרן יכול להסמיך מתקינים ולתחום את הפעולות שהם מורשים לבצע.

המשמעות מעניינת בבניין עם מאות גופי תאורה: לא בהכרח צריך להגיע פיזית למדבקה של כל גוף כדי להכניסו לרשת, אבל כן צריך כלי התקנה בעל סמכות מתאימה. זה מקרב את תהליך ההתקנה למודל של ניהול ציוד מקצועי. עם זאת, התמיכה אופציונלית; אי־אפשר לייחס אותה לכל מוצר Thread. תעודות ההתקנה גם אינן הופכות אוטומטית כל הודעת יישום למוגנת מקצה לקצה.

Matter: תעודת מקוריות אינה הרשאה לפתוח דלת

Matter מוסיף שכבת יישום, ויכול לפעול מעל Thread או רשתות אחרות. בעת ההתקנה משתמשים בקוד ההתקנה להקמת ערוץ מוגן. בנפרד בודקים את מקוריות המכשיר באמצעות תעודת יצרן והוכחת החזקה במפתח שלה. לאחר מכן מקימים זהות תפעולית המשתייכת לתחום האמון של ההתקנה, הנקרא Fabric. אלו תפקידים שונים: ״מכשיר מקורי״, ״חבר במערכת שלי״ ו״מורשה לבצע פעולה מסוימת״.

כך אפשר לבנות אבטחת יישום שאינה מסתפקת בכך שמכשיר מכיר את מפתח הרשת האלחוטית. למשל, נתב שמעביר תעבורה אינו צריך לקבל בשל כך הרשאת שליטה במנעול. בהשוואה הוגנת צריך להציב מול Matter יישום מאובטח שרץ על Wi-SUN, ולא להשוות את מלוא שכבות Matter להגנת הרדיו בלבד.

באוגוסט 2025 הרחיבה Matter 1.4.2 את התמיכה התקנית ברשימות שלילת תעודות, לצד בקרות נוספות. רשימה כזאת מאפשרת לפרסם שתעודה שהייתה תקינה אינה אמינה עוד. היישום המעשי כולל בדיקת המידע ומדיניות תגובה בזמן ההתקנה. אין פירוש הדבר שהגרסה המציאה את עצם רעיון השלילה, או שהיא מנתקת מיד כל מכשיר שכבר מותקן.

ביוני 2026 הוסיפה Matter 1.6 רשימות שלילה המחולקות לחלקים שניתן לעדכן בנפרד. במקום לטפל תמיד ברשימה גדולה אחת, תשתית האמון יכולה להפיץ עדכונים בהיקף מצומצם יותר. זה חידוש באבטחה בקנה מידה גדול: השאלה אינה רק אם יודעים לבדוק חתימה, אלא אם אפשר להפיץ מידע עדכני על אמון כשהמערכת גדלה. זו יכולת במפרט; קצב הופעתה במוצרים תלוי ביצרנים ובפלטפורמות.

LoRaWAN: בלי תעודה ציבורית, אבל לא בלי זהות ייחודית

ב־LoRaWAN חשוב לתקן טעות נפוצה: שימוש בהצפנה סימטרית אינו אומר שלכל החיישנים חייב להיות אותו סוד. בהפעלה דרך האוויר, המכשיר מתחיל ממפתחות שורש ייחודיים שכבר הוכנסו אליו וידועים לצד המורשה בתשתית. הליך ההצטרפות מאמת את חילופי ההודעות ומפיק מפתחות להפעלה. ״דרך האוויר״ מתאר כיצד מתחילים הפעלה, לא יצירת אמון מאפס ללא סוד מוקדם.

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

כאן אין צורך לנהל לכל חיישן שרשרת תעודות ציבוריות, אבל יש אחריות לשמירה ולהקצאה נכונה של סודות ייחודיים. פגיעה במאגר מפתחות מרכזי שונה מאוד מפגיעה בחיישן בודד. הפרדת המפתחות של 1.1 היא תכונה ותיקה, לא חידוש של 2026; גם מספר גרסה חדש במסמך פרמטרי הרדיו האזוריים אינו בהכרח גרסת אבטחה חדשה. לא נמצא במחקר בסיס להציג כאן המצאה קריפטוגרפית חדשה המקבילה בזמן לשינויי Matter. עדיף לומר זאת מאשר לייצר חידוש מלאכותי.

וגם Bluetooth Mesh כבר אינו ״רק קוד התאמה״

ב־Bluetooth Mesh 1.1 נוספה ב־2023 אפשרות לצירוף התקנים על בסיס תעודות. תעודה יכולה לקשור את זהות ההתקן למפתח הציבורי שלו וכך לסייע באימות בזמן ההתקנה. זו אפשרות נוספת, לא תכונה שקיימת בהכרח בכל מוצר. היא מדגימה את המגמה הרחבה: גם מערכות שיועדו להתקנה מקומית מאמצות כלים לניהול זהויות בכמויות גדולות. תעודה תקינה עדיין אינה מחליפה את ההחלטה שהמכשיר המסוים מורשה לאתר המסוים.

אז במה Wi-SUN באמת בולט, ואיפה צריך להשלים אותו?

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

מבחן טוב למערכת הוא תרחיש אחד: מחר בבוקר נתב תאורה נגנב. האם אפשר לחסום את זהותו, להפסיק לקבל את המפתחות הישנים, להשאיר את מדי המים התקינים מחוברים, ולמנוע מהנתב הגנוב לפקד על שסתום? התשובות תלויות גם בתשתית האימות, בתוכנת המוצר וביישום שמעל FAN. אף לוגו אינו עונה על כל השאלות האלה לבדו.

לפני בחירת ספק כדאי לדרוש תיאור של חמישה דברים: היכן נשמר המפתח הפרטי ומי יכול להשתמש בו; מי רשאי לאשר התקן חדש; כיצד חוסמים התקן שכבר הצטרף; כמה זמן נמשכת החלפת המפתחות בתנאי ניתוק; ומי מחזיק במפתחות שמאפשרים לקרוא או לשנות את מדידות היישום. אלה שאלות רכש ותכנון שנגזרות מהארכיטקטורה, לא דרישות הסמכה חדשות שהמצאנו.

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

על מה משלמים כשאומרים ״אישור״ או ״חתימה״?

תעודת תאימות ל־FAN מאשרת שהמימוש נבדק מול הפרופיל; היא אינה תעודת הזהות הדיגיטלית של כל יחידה. במסלול הרגיל, חברה עם הכנסות מתחת ל־100 מיליון דולר משלמת $5,000 לשנה על חברות Contributor ו־$3,000 אגרת הסמכת FAN למוצר. יחד מדובר ב־$8,000 בשנה הראשונה, לפני מעבדה ועלויות נוספות. חברות זולה יותר בשם Adopter אינה מספיקה להסמכת מוצר במסלול המתואר.

הנפקת זהויות למכשירים היא תקציב אחר. Wi-SUN Alliance מתירה תעודות מגוף מאשר חיצוני או מהיצרן, בכפוף לדרישותיה. לא נמצא מחיר פומבי אחיד להנפקה ולהכנסת המפתח המאובטחת בייצור. גם כשמנהלים את הגוף המאשר לבד, צריך להגן על מפתח החתימה, לנהל הרשאות ולתכנן טיפול בהתקנים שנפגעו. זה אינו תשלום עבור כל מדידה, אלא אחריות מתמשכת על הזהויות ועל האמון ברשת.

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