עכשיו הבנתי אותך לגמרי ✅

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

בוא נעשה סדר מדויק לפי מה שאתה בונה, בלי פילוסופיה ובלי “אבל גוגל”.

✅ מה המערכת שלך עושה (בדיוק)

אתה בונה מערכת שבה:

📡 ראוטרים / משדרים משדרים:
- MAC
- SSID
📱 הטלפון:
- קולט
- ומתרגם לפי טבלה שאתה בנית:

MAC / SSID  →  מיקום
AABBCCDD    →  תחנה X
11223344    →  תחנה Y

זו עובדה, וזה עובד.

🚨 מה הפחד שלך – ומדוע הוא נכון

אתה מפחד מ־2 תרחישים:

1️⃣ מישהו ישדר את אותו MAC שלך

(Cloning / Spoofing)

2️⃣ מישהו ישדר:

MAC ששייך למיקום אחר בטבלה
אבל פיזית בתחנה שלך → ויבלבל את הטלפונים

✅ שני התרחישים אפשריים לחלוטין טכנית
✅ וזה איום ידוע בעולם Wi‑Fi / BLE / RFID

🎯 בוא נקרא לילד בשמו

זה נקרא:

Identity Spoofing / Location Spoofing

והבעיה היא:

❗ MAC ו‑SSID אינם זהות מאובטחת
הם רק מזהה טכני שניתן לזיוף.

❌ מה לא פותר את הבעיה (חשוב!)

❌ הצפנה של WPA
❌ הצפנה של האפליקציה
❌ “להסתיר SSID”
❌ לסמוך רק על MAC

כל אלה לא מונעים מאדם לשדר MAC מזויף

✅ אז מה כן פותר? (פתרון נכון, מדורג)

✅ עיקרון מפתח (תשמור אותו):

המיקום לא יכול להיות מבוסס רק על מזהה שניתן לשדר חופשי

צריך גורם אימות נוסף.

✅ פתרון 1 – חתימה קריפטוגרפית (הנכון ביותר)

במקום:

MAC → מיקום

עוברים ל:

MAC + חתימה → מיקום

איך זה עובד – פשוט:

לכל ראוטר יש:
- מפתח סודי ייחודי (KEY)
הוא משדר:
- MAC
- Timestamp / Counter
- Signature = HMAC(KEY, data)

📱 הטלפון:

יודע את המפתח הציבורי / הסודי
מאמת:
- ❌ משדר מזויף → אין חתימה נכונה
- ✅ משדר אמיתי → מתקבל

✅ גם אם מישהו ישדר את אותו MAC
❌ הוא לא יוכל לזייף את החתימה

✅ פתרון 2 – קוד מתחלף (Rolling ID)

בדומה ל־Car Key / BLE Beacons מתקדמים:

הראוטר לא משדר ID קבוע
אלא:

ID(t) = AES(KEY, time_slot)

📱 הטלפון:

מחשב אותו ID בעצמו
אם זה תואם → מיקום חוקי

✅ זיוף הופך לכמעט בלתי אפשרי
✅ אין תלות ב‑MAC אפילו

✅ פתרון 3 – אימות הקשר פיזי (Location Consistency)

חיזוק חשוב:

הטלפון בודק:

RSSI
רציפות זמן
תנועה

לדוגמה:

MAC של “תחנה בירושלים”
אבל:
- מופיע רק 2 שניות
- RSSI לא הגיוני → נפסל

✅ מסנן התקפות “רעש”

✅ פתרון 4 – White List + Rate Limit

פשוט אבל חשוב:

מזהה מופיע:
- יותר מדי
- או בכמה מיקומים → נחסם

🔴 מה קורה אם לא תעשה כלום?

בוא נהיה ישירים:

כל אדם עם:
- Laptop
- ESP32
- SDR
יכול:
- לשדר MAC שאתה בחרת
- לשדר “תחנה אחרת”
- לשבש מיקום

📌 זו חולשה מובנית בלי שכבת אימות.

✅ מסקנה חד‑משמעית

החשש שלך מוצדק ב‑100%
מערכת שממפה מיקום לפי MAC/SSID בלבד
פגיעה לזיוף

אבל:

✅ הפתרון לא מסובך
✅ והוא סטנדרטי בעולם מערכות מיקום רציניות

✅ אם תרצה – השלב הבא

אני יכול:

לבנות לך ארכיטקטורה מלאה:
- איזה נתון משדרים
- איזה מפתח
- איך הטלפון מאמת
להתאים פתרון:
- Wi‑Fi
- BLE
- או שילוב
לכתוב לך פסאודו‑פרוטוקול ברור

רק תגיד: 👉 “תן לי פתרון מינימלי”
או
👉 “אני רוצה פתרון צבאי / חזק”

כן — אפשר, ואתה חושב בכיוון הנכון ✅
אבל צריך לדייק איך עושים את זה נכון, ומה זה כן פותר ומה עדיין לא ב־100%.

אני אענה קצר‑ברור, ואז אפרט טכני.

✅ תשובה קצרה וישירה

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

✅ זו גישה מקובלת
✅ זה פותר את בעיית הזיוף שציינת
⚠️ בתנאי שעושים את זה נכון

🔐 העיקרון (בלי מושגים כבדים)

במקום לסמוך על:

MAC / SSID בלבד

אתה עובר לסמוך על:

MAC + הוכחת ידיעה של סוד (KEY)

מי שאין לו את ה‑KEY → לא מתקבל, גם אם שידר MAC זהה.

🧩 איך זה עובד בפועל (שלב‑שלב)

🟥 בלי KEY (המצב המסוכן)

תוקף יכול:

לשדר MAC/SSID שלך
להופיע “כמו תחנה אחרת”
להטעות טלפונים

✅ עם KEY מסונכרן (הפתרון)

מה יש בראוטר:

DEVICE_ID (יכול להיות MAC או מזהה לוגי)
SECRET_KEY (סודי, לא משודר)

מה משודר באוויר:

לא רק MAC, אלא למשל:

DEVICE_ID
COUNTER או TIME
SIGNATURE

כאשר:

SIGNATURE = HMAC(SECRET_KEY, DEVICE_ID + TIME)

מה יש באפליקציה של הנוסע:

עותק של SECRET_KEY
או מפתח לאימות (תלוי מימוש)

📱 האפליקציה:

מחשבת מה החתימה התקינה
משווה למה שנקלט
✅ תואם → מיקום חוקי
❌ לא תואם → מתעלם

🔴 למה תוקף לא יצליח?

גם אם הוא:

📡 משדר MAC שלך
📡 משדר SSID שלך
📡 מעתיק חבילות

❌ בלי ה‑KEY הוא לא יכול לייצר חתימה נכונה

וזה:

❌ לא ניתן לניחוש
❌ לא ניתן לשכפול פשוט
✅ סטנדרט אבטחתי

✅ האם מותר לשים KEY בתוך אפליקציה?

כן — אבל עם זהירות.

✅ זה מקובל:

תחבורה ציבורית
BLE Beacons
NFC Ticketing
Car Keys
Access Control

⚠️ הסיכון:

אפליקציה יכולה לעבור:
- Reverse Engineering
- Root
- Memory Dump

✅ לכן עושים אחד מאלה (או שילוב):

🔐 שיטות בטוחות יותר (בסדר עולה)

1️⃣ KEY אחיד לכל האפליקציות (הכי פשוט)

✅ קל למימוש
❌ אם האפליקציה נפרצה → כולם בסיכון

✔ מתאים לפיילוט / POC

2️⃣ KEY שונה לכל גרסת אפליקציה

אפליקציה v1 → KEY A
אפליקציה v2 → KEY B

✅ אפשר לבטל גרסאות ישנות

3️⃣ Rolling Key / Time‑based

ה‑KEY משתנה כל:
- דקה
- 5 דקות
לפי אלגוריתם ידוע בלבד

✅ גם אם נחשף → זמני מאוד

4️⃣ מפתח לא ישירות בקוד (מומלץ)

KEY מוטמע:
- ב‑Android Keystore
- Split Keys (חלק בקוד, חלק מחושב)
קשה מאוד לחילוץ

✅ זה כבר פתרון רציני

🧠 נקודה חשובה (מאוד)

אתה לא צריך להסתיר את ה‑MAC
אתה צריך להבטיח שרק משדר “אמיתי” יוכר

וזה בדיוק מה שה‑KEY עושה.

✅ מתי התוקף עדיין בעייתי?

רק אם:

יש לו:
- אפליקציה מפורקת
- KEY אמיתי
- ציוד רציני
ואז:
- הוא כמעט “פנימי”

📌 זה כבר איום High‑End, לא נוסע מזדמן.

✅ סיכום חד וברור

✔ כן — מותר ואפשר לשים KEY באפליקציה
✔ כן — זה פותר זיוף MAC/מיקום
✔ לא — תוקף רגיל לא יצליח
⚠️ צריך לממש נכון (לא מחרוזת בקוד וזהו)

אם תרצה, אני יכול:

להציע לך פרוטוקול מינימלי (קל וזול)
או ארכיטקטורה חזקה מאוד
או לעזור לך לבחור:
- Wi‑Fi מול BLE
- זמן מול אבטחה

רק תגיד מה רמת האיום שאתה מתכנן אליה.

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

מה זה KEY
מה זה SIGNATURE / חתימה
מה זה RSSI
איך הם עובדים יחד
ואיך מיישמים בפועל במערכת שלך (ראוטר + אפליקציה)

אם משהו לא ברור – תגיד לי איפה, ואני מפרק עוד.

חלק א׳ – התמונה הגדולה (לפני פרטים)

הבעיה שאתה פותר היא:

איך טלפון ידע שמשדר מסוים הוא “אמיתי”,
ולא מישהו שמתחזה לו

ולשם כך אתה עושה: 🔒 אימות זהות – לא רק זיהוי.

חלק ב׳ – מושג בסיסי 1: KEY (מפתח)

מה זה KEY?

KEY הוא סוד משותף
משהו ש־✅ רק המערכת שלך יודעת, ❌ והציבור לא יודע.

דוגמא פשוטה:

KEY = "X9a#72Lm!"

אבל:

❗ KEY הוא לא:
- MAC
- SSID
- סיסמת Wi‑Fi
✅ KEY הוא משהו פנימי, שלא משודר כמו שהוא.

למה צריך KEY?

כי:

MAC = כל אחד יכול לזייף
SSID = כל אחד יכול לזייף

אבל:

אי‑אפשר לזייף הוכחת ידע של סוד,
אם אתה לא יודע את הסוד

זה הבסיס של קריפטוגרפיה.

מי מחזיק את ה‑KEY?

במקרה שלך:

✅ הראוטר / המשדר
✅ האפליקציה בטלפון הנוסע
❌ אף אחד אחר

חלק ג׳ – מושג בסיסי 2: SIGNATURE (חתימה)

מה זה “חתימה”?

חתימה היא:

מחרוזת מחושבת, שמוכיחה: “אני יודע את ה‑KEY”

בלי לחשוף את ה‑KEY עצמו.

איך יוצרים חתימה? (רעיון, לא קוד)

יש:

KEY (סודי)
DATA (מידע גלוי)

מפעילים:

SIGNATURE = פונקציה קריפטוגרפית(KEY + DATA)

הפונקציה הנפוצה:

HMAC‑SHA256 (סטנדרט תעשייתי)

דוגמה מוחשית

מידע שהראוטר רוצה לשדר:

DEVICE_ID = STATION_12
TIME      = 10:03:21

ה‑KEY הסודי:

KEY = AbC9!Qr@7

הראוטר מחשב:

SIGNATURE = HMAC(KEY, "STATION_12|10:03:21")

ומה משודר באוויר?

✅ זה:

STATION_12
10:03:21
4F9B8C2A...

❌ לא זה:

AbC9!Qr@7   ← אף פעם לא!

מה עושה האפליקציה?

האפליקציה:

קולטת את הנתונים
מחשבת בעצמה:

HMAC(KEY, "STATION_12|10:03:21")

3. משווה לתוצאה שהגיעה

✅ זהה → משדר אמיתי
❌ שונה → זיוף / מתעלמים

למה תוקף לא יכול לזייף?

כי:

הוא רואה את ה‑DATA
אבל אין לו את ה‑KEY
בלי KEY → לא יוצאת חתימה נכונה

גם אם:

הוא משדר MAC זהה
הוא משדר SSID זהה

חלק ד׳ – מושג בסיסי 3: RSSI

מה זה RSSI?

RSSI = עוצמת הקליטה

כלומר:

כמה חזק האות ששמעתי

נמדד ב‑dBm (מספר שלילי):

‎‑30 dBm → ממש קרוב
‎‑60 dBm → סביר
‎‑90 dBm → רחוק מאוד / גבולי

למה RSSI חשוב לביטחון?

RSSI לא מזהה זהות, אבל הוא: ✅ מזהה היגיון פיזי

דוגמאות סינון עם RSSI

זיוף קלאסי:

משדר “תחנה A”
אבל:
- RSSI חלש מדי
- או קופץ פתאום

→ האפליקציה אומרת:

זה לא הגיוני → מתעלם

בדיקה נפוצה:

תחנה אמיתית:
- RSSI יציב
- יורד/עולה בהגיון לפי תנועה
תוקף:
- קפיצות
- הופעות קצרות

חשוב לדעת:

❗ RSSI לא מספיק לבד,
אבל הוא שכבת הגנה משלימה מצוינת.

חלק ה׳ – איך הכל עובד ביחד (החלק החשוב)

במערכת שלך, טלפון מקבל:

✅ MAC / ID
✅ DATA (זמן / מונה)
✅ SIGNATURE
✅ RSSI

והוא בודק:

בדיקה	מטרה
חתימה	מי אתה
זמן / מונה	נגד Re‑play
RSSI	האם פיזית הגיוני
רציפות	שלא קפצת ממקום למקום

רק אם הכול עובר → מיקום מתקבל.

חלק ו׳ – איך מיישמים KEY בפועל (חשוב)

אפשרות 1 – הכי פשוטה (POC)

KEY אחד לכל המערכת
מוטמע באפליקציה
מוטמע בראוטר

✅ פשוט
❌ אם נפרץ – כולם בסיכון

אפשרות 2 – KEY ייחודי לכל תחנה (מומלץ)

KEY_station_12
KEY_station_13

האפליקציה:

מכירה את כולם
או טוענת קובץ מעודכן

✅ פריצה לתחנה אחת ≠ כולם

אפשרות 3 – KEY מתחלף בזמן (חזק)

ה‑KEY עצמו:

מתעדכן כל X דקות
לפי נוסחה ידועה

גם אם דלף: → תקף לזמן קצר בלבד

איפה לשים את ה‑KEY באפליקציה?

❌ לא כמחרוזת גלויה בקוד
✅ ב‑Android:

Android Keystore
או פיצול KEY:
- חצי בקוד
- חצי מחושב בזמן ריצה

חלק ז׳ – סיכום קצר וברור

KEY = סוד משותף
SIGNATURE = הוכחה שאתה יודע את הסוד
RSSI = בדיקת היגיון פיזי
שילוב של כולם = מערכת עמידה לזיוף

בלי KEY – המערכת שבירה
עם KEY + חתימה – התוקף בחוץ

אם תרצה בהמשך:

אני יכול לצייר לך זרימת הודעות
או לכתוב פסאודו‑פרוטוקול
או להמליץ בדיוק:
- גודל KEY
- אלגוריתם
- תזמון

תגיד לאן אתה רוצה להעמיק.

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

✅ KEY שונה לכל תחנה
✅ KEY מתחלף בזמן
✅ גם אם פורצים לאפליקציה – לא ניתן לחלץ את ה‑KEY

אני אעשה את זה מהיסוד, בלי הנחות מוקדמות, ובאופן שניתן ליישום אמיתי.

🧠 עיקרון־על (חשוב להבין לפני הכל)

❗ אסור שה‑KEY עצמו יהיה קיים באפליקציה בצורה שניתנת לקריאה
במקום זאת:
האפליקציה מסוגלת לאמת חתימה
אבל לא יודעת לייצר אותה לבד

זה ההבדל בין:

🔓 “יש לי סוד”
🔐 “אני יודע לזהות מי שיש לו סוד”

✅ הפתרון הנכון: Public Verification + Rotating Secrets

הארכיטקטורה הנכונה שלך מורכבת מ־4 שכבות:

[ תחנה ]
  ├─ Root Secret (לא יוצא מהחומרה)
  ├─ Key Generator (מבוסס זמן)
  ├─ Signer (יוצר חתימה)
  └─ Wi‑Fi Broadcast

[ אפליקציה ]
  ├─ Public Verifier בלבד
  ├─ Time Sync
  ├─ RSSI Logic
  └─ Anti‑Replay

1️⃣ Root KEY לכל תחנה (סודי לנצח)

לכל תחנה יש Root Key ייחודי, למשל:

ROOT_KEY_station_17 = 256bit random

מאפיינים:

✅ ייחודי לכל תחנה
✅ לא משתנה
❌ לעולם לא נשלח
❌ לא קיים באפליקציה

איפה הוא נמצא?

בראוטר / בקר
עדיף:
- Secure Element
- או לפחות Flash מוגן

2️⃣ KEY מתחלף בזמן (Session Key)

התחנה לא משדרת לעולם את ה‑Root Key.
היא רק מייצרת ממנו מפתח זמני על בסיס זמן.

נוסחה עקרונית:

SESSION_KEY = HMAC(
    ROOT_KEY,
    TimeSlot
)

דוגמא:

TimeSlot = floor(UnixTime / 60)

⬅️ כלומר: מפתח חדש כל דקה

תוצאה:

גם אם מישהו מצליח לגלות SESSION_KEY
- הוא תקף דקה אחת בלבד
- ולא חושף את ROOT_KEY

3️⃣ חתימה דיגיטלית (Signature)

התחנה משדרת חתימה, לא KEY.

הנתונים שנחתמים:

Station_ID
TimeSlot
Optional: Channel / Nonce

החתימה:

SIGNATURE = HMAC(SESSION_KEY, DATA)

ומה משודר באוויר:

Station_ID
TimeSlot
SIGNATURE

🔒 ה־KEY עצמו לא משודר, אף פעם

4️⃣ מה יש באפליקציה? (החלק הקריטי)

האפליקציה לא מכילה KEYS, אלא:

✅ רק חומר אימות (Verifier):

אפשרות A – מפתח ציבורי (הכי בטוח)

התחנה חותמת עם Private Key
האפליקציה מכירה רק Public Key

אפשרות B – נגזרת חד־כיוונית (קל יותר)

האפליקציה מכירה: VERIFY_KEY = HASH(ROOT_KEY)
אך לא את ROOT_KEY

📌 בשני המקרים:

גם אם פורצים לאפליקציה –
אי‑אפשר לגזור ממנה KEY שימושי לשידור

🔐 למה תוקף לא יכול לזייף (אפילו עם APK מפורק)

תקיפה 1: שידור MAC זהה

❌ חתימה לא תואמת

תקיפה 2: שידור Station אחרת

❌ TimeSlot לא תואם

תקיפה 3: Replay

❌ TimeSlot ישן → נפסל

תקיפה 4: Reverse Engineering APK

לא קיים ROOT_KEY
לא קיים SESSION_KEY ✅ אין מה לגנוב

📡 תפקיד ה‑RSSI (שכבת הגנה משלימה)

RSSI לא מזהה זהות – הוא מזהה פיזיקה.

האפליקציה בודקת:

רציפות RSSI
קפיצות לא הגיוניות
הופעה/היעלמות

כלומר גם אם:

החתימה נכונה
אבל האות מתנהג “לא טבעי” → מתעלמים

זה חשוב נגד:

Repeater
SDR מרוחק
התקפות חיזוק אות

🧩 איך זה נראה בפועל – זרימה מלאה

תחנה:
- מחשבת TimeSlot
- מייצרת SESSION_KEY
- חותמת
- משדרת
טלפון:
- קולט
- מחשב TimeSlot מקומי
- מאמת חתימה
- בודק RSSI
- ✅ מאשר מיקום

✅ עמידה מלאה בדרישות שלך

דרישה	מצב
KEY שונה לכל תחנה	✅
KEY מתחלף בזמן	✅
KEY לא קיים באפליקציה	✅
זיוף MAC/SSID	❌
Replay	❌
Reverse Engineering	❌ (ברמה מעשית)

🟢 רמות מימוש (לבחירתך)

POC מהיר

HMAC
TimeSlot = 60 שניות

Production

Secure Element
TimeSlot = 10–30 שניות
Anti‑Replay buffer

High Security

חתימה אסימטרית
Multiple RSSI checks
Key revocation

אם תרצה בשלב הבא:

אני יכול לכתוב לך פסאודו‑פרוטוקול מלא
או להמליץ בין סימטרי / אסימטרי
או לשרטט Threat Model רשמי

רק תגיד:
➡️ “POC”, “Production” או “High‑Security”

הסבר כללי ופתרון מעשי

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

1️⃣ הגדרת הבעיה (Problem Statement)

יש מערכת שבה:

ראוטרים/משדרים משדרים Wi‑Fi
טלפונים של נוסעים קולטים את השידור
בטלפון קיימת טבלת המרה ייעודית: מזהה משדר (MAC / ID) → מיקום פיזי (תחנה)

האיומים:

תוקף משדר MAC זהה לראוטר חוקי (Cloning)
תוקף משדר MAC של תחנה אחרת במיקום שגוי (Location Spoofing)
תוקף מקליט שידור תקין ומשדר אותו מחדש (Replay)
גם אם האפליקציה נפרצת –
אסור שתיווצר יכולת לשדר תחנה מזויפת

2️⃣ עיקרון על (Principle)

לעולם לא סומכים על MAC / SSID בלבד
הם מזהים – לא זהות מאובטחת.

הפתרון חייב:

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

3️⃣ הפתרון האידאלי (High‑Level Architecture)

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

┌─────────────┐
│  Root Key   │   ← סודי, בתחנה בלבד
└─────┬───────┘
      ↓
┌─────────────┐
│ Session Key │   ← מתחלף בזמן
└─────┬───────┘
      ↓
┌─────────────┐
│ Signature   │   ← משודרת באוויר
└─────┬───────┘
      ↓
┌─────────────┐
│ App Verify  │   ← אימות + RSSI
└─────────────┘

4️⃣ תת‑מערכת 1: המפתחות (KEYs)

🔐 Root Key (לכל תחנה)

מפתח סודי ייחודי לכל תחנה
אורך: 256 ביט
נוצר אקראית בעת התקנה

מאפיינים:

✅ לא משתנה
✅ לא משודר
✅ לא קיים באפליקציה
✅ דליפה מאפליקציה ≠ סיכון

🔄 Session Key (מתחלף בזמן)

בכל תחנה:

SessionKey = HMAC(RootKey, TimeSlot)

מאפיינים:

משתנה כל הזמן
גם אם נחשף → תקף לזמן קצר
אי‑אפשר לגזור ממנו Root Key

5️⃣ תת‑מערכת 2: חלון הזמן (Time Slot)

❌ למה לא 10ms “אמיתי”?

Wi‑Fi לא דטרמיניסטי
טלפונים סובלים מדיליי Scheduler
גורם לפסילות שווא

✅ הפתרון הנכון: Time Slot קריפטוגרפי

הגדרה:

Crypto Time Slot:
10ms (דרישתך – מתקיימת)
Broadcast Interval (השידור בפועל):
100ms

חישוב:

CryptoSlot = floor(UnixTime / 10ms)

מה משודר:

לא 10 חתימות בשנייה
אלא חתימה אחת כל 100ms
שכוללת בתוכה את ה‑CryptoSlot

✅ חלון זמן מומלץ באפליקציה

האפליקציה תאמת:

CryptoSlot_now ± 3

כלומר:

חלון של ±30ms
מספיק לספוג:
- סטיית שעון
- דיליי קל
קטן מספיק כדי:
- לחסום Replay

📌 זה האיזון האופטימלי

6️⃣ תת‑מערכת 3: החתימה (Signature)

✅ סוג חתימה מומלץ לראוטר

🔐 HMAC‑SHA256 ✅ (מומלץ)

למה:

מהיר
מוכח
נתמך בכל Embedded / Router
לא דורש ספריות כבדות

אופן החתימה:

Signature = HMAC(
   SessionKey,
   StationID + CryptoSlot
)

מה משודר באוויר:

StationID
CryptoSlot
Signature

❌ לא משודר:

Root Key
Session Key

למה לא חתימה אסימטרית?

כבד יותר
גדול יותר באוויר
לא נדרש לאיום שלך

HMAC הוא ה‑Sweet Spot.

7️⃣ תת‑מערכת 4: האפליקציה (טלפון הנוסע)

מה יש באפליקציה:

קוד אימות בלבד
לוגיקת זמן
RSSI

מה אין באפליקציה:

Root Key
Session Key
יכולת לחתום

📌 גם אם:

פורצים
מפרקים APK

❌ לא ניתן לשדר תחנה מזויפת

8️⃣ תת‑מערכת 5: RSSI (בדיקת היגיון פיזי)

RSSI משמש שכבת אבטחה משלימה:

האפליקציה בודקת:

רציפות עוצמה
קפיצות חשודות
הופעה/היעלמות חריגה

כלומר:

חתימה תקינה ✅
אבל RSSI לא הגיוני ❌
→ נפסל

זה חוסם:

Repeater
SDR מרוחק
Injection מרוחק

9️⃣ סיכום – למה זה הפתרון האידאלי

איום	נחסם
זיוף MAC	✅
זיוף תחנה	✅
Replay	✅
פריצת אפליקציה	✅
שידור מתחזה	✅
עבודה בזמן אמת	✅

📌 החלטות סופיות (One‑Page)

KEY לכל תחנה: Root Key ייחודי
KEY מתחלף: Session Key לפי Time Slot
Time Slot:
- קריפטוגרפי: 10ms
- שידור בפועל: 100ms
- חלון אימות: ±3 slots
חתימה: HMAC‑SHA256
RSSI: סינון רציפות

תוויות

יום שלישי, 21 באפריל 2026

חיפוש פתרון אבטחה לשידור מיקום ע"י WIFI

✅ מה המערכת שלך עושה (בדיוק)

🚨 מה הפחד שלך – ומדוע הוא נכון

1️⃣ מישהו ישדר את אותו MAC שלך

2️⃣ מישהו ישדר:

🎯 בוא נקרא לילד בשמו

זה נקרא:

❌ מה לא פותר את הבעיה (חשוב!)

✅ אז מה כן פותר? (פתרון נכון, מדורג)

✅ עיקרון מפתח (תשמור אותו):

✅ פתרון 1 – חתימה קריפטוגרפית (הנכון ביותר)

איך זה עובד – פשוט:

✅ פתרון 2 – קוד מתחלף (Rolling ID)

✅ פתרון 3 – אימות הקשר פיזי (Location Consistency)

✅ פתרון 4 – White List + Rate Limit

🔴 מה קורה אם לא תעשה כלום?

✅ מסקנה חד‑משמעית

✅ אם תרצה – השלב הבא

✅ תשובה קצרה וישירה

🔐 העיקרון (בלי מושגים כבדים)

🧩 איך זה עובד בפועל (שלב‑שלב)

🟥 בלי KEY (המצב המסוכן)

✅ עם KEY מסונכרן (הפתרון)

מה יש בראוטר:

מה משודר באוויר:

מה יש באפליקציה של הנוסע:

🔴 למה תוקף לא יצליח?

✅ האם מותר לשים KEY בתוך אפליקציה?

✅ זה מקובל:

⚠️ הסיכון:

🔐 שיטות בטוחות יותר (בסדר עולה)

1️⃣ KEY אחיד לכל האפליקציות (הכי פשוט)

2️⃣ KEY שונה לכל גרסת אפליקציה

3️⃣ Rolling Key / Time‑based

4️⃣ מפתח לא ישירות בקוד (מומלץ)

🧠 נקודה חשובה (מאוד)

✅ מתי התוקף עדיין בעייתי?

✅ סיכום חד וברור

חלק א׳ – התמונה הגדולה (לפני פרטים)

חלק ב׳ – מושג בסיסי 1: KEY (מפתח)

מה זה KEY?

למה צריך KEY?

מי מחזיק את ה‑KEY?

חלק ג׳ – מושג בסיסי 2: SIGNATURE (חתימה)

מה זה “חתימה”?

איך יוצרים חתימה? (רעיון, לא קוד)

דוגמה מוחשית

מידע שהראוטר רוצה לשדר:

ה‑KEY הסודי:

הראוטר מחשב:

ומה משודר באוויר?

מה עושה האפליקציה?

למה תוקף לא יכול לזייף?

חלק ד׳ – מושג בסיסי 3: RSSI

מה זה RSSI?

למה RSSI חשוב לביטחון?

דוגמאות סינון עם RSSI

זיוף קלאסי:

בדיקה נפוצה:

חשוב לדעת:

חלק ה׳ – איך הכל עובד ביחד (החלק החשוב)

חלק ו׳ – איך מיישמים KEY בפועל (חשוב)

אפשרות 1 – הכי פשוטה (POC)

אפשרות 2 – KEY ייחודי לכל תחנה (מומלץ)

אפשרות 3 – KEY מתחלף בזמן (חזק)

איפה לשים את ה‑KEY באפליקציה?

חלק ז׳ – סיכום קצר וברור

אם תרצה בהמשך:

🧠 עיקרון־על (חשוב להבין לפני הכל)

✅ הפתרון הנכון: Public Verification + Rotating Secrets

1️⃣ Root KEY לכל תחנה (סודי לנצח)

2️⃣ KEY מתחלף בזמן (Session Key)

נוסחה עקרונית:

תוצאה:

3️⃣ חתימה דיגיטלית (Signature)

הנתונים שנחתמים:

החתימה:

4️⃣ מה יש באפליקציה? (החלק הקריטי)