Day 21 的接收車輛收到格式正確且可能具有有效簽章的 V2X 訊息，內容卻宣告不存在的壅塞事件。問題不只在於「有沒有加密」，而是外部資料跨過信任邊界後，系統用什麼條件決定放行、採信、降權或留下證據。

今天把防線放回完整資料流：

V2X／Cellular／診斷入口
  → 身分與權限驗證
  → Secure Gateway 執行分區及白名單規則
  → IDS 觀察頻率、時序與內容合理性
  → 接收應用比對 Ground Truth 或其他感測來源
  → 採用、降權、隔離或告警
  → Event Log 保存判斷依據

單一控制無法回答所有問題。驗證簽章不會讓位置自動成真，Gateway 放行也不代表業務內容合理，而 IDS（Intrusion Detection System，入侵偵測系統）發出告警更不等於已證明攻擊成立。

今天的學習目標

讀完這篇文章，你應該能夠：

1. 分辨 IDS、Secure Gateway、Authentication 與 Segmentation 的角色
2. 沿著資料流安排預防、偵測、回應及證據保存
3. 為 Day 21 的假位置案例設計可解釋的偵測規則
4. 說明誤報、漏報與安全退化之間的取捨
5. 把防護措施寫成可驗證的需求，而不是產品名稱清單

核心概念：四種控制各自回答不同問題

Authentication 是身分驗證或訊息真實性檢查。它保護的是「受保護內容由持有相應金鑰或憑證的實體送出，途中未被任意修改」這類命題。若合法節點遭入侵，或感測來源本來就錯誤，驗證仍可能成功。

Secure Gateway 是具備安全政策執行能力的車載閘道器。它不應只是把 CAN 與 Automotive Ethernet 轉換格式，而要根據架構定義哪些診斷服務、訊息或連線能跨越信任邊界。Network Segmentation（網路分區）則先縮小可達範圍，避免資訊娛樂或對外通訊元件取得不必要的控制區連線。

IDS 負責觀察。規則式 IDS 可以檢查已知週期、Identifier、Data Length Code、服務狀態及允許方向。異常式 IDS 會從 Baseline 學習正常分布，再找出偏離。兩者都需要可解釋的 Ground Truth，否則「不同於昨天」可能只是正常軟體更新或交通情境改變。

IDS 放在哪裡，會看見不同真相

車內 IDS 若接在單一 CAN 區段，可以看見 Frame 時序與錯誤事件，卻未必知道 Cellular Session 的帳號或 V2X 憑證結果。Gateway 型 IDS 能對照跨區前後的資料流，但要避免把所有流量集中成新的效能瓶頸。後端 IDS 看得到大量車隊事件，適合找出跨車輛趨勢，卻不能取代車內毫秒級的安全退化。

因此事件要能串接共同欄位，例如車輛匿名識別、ECU 邏輯來源、介面、規則版本、模擬時間與關聯 ID。記錄內容也要考慮資料最小化，不能為了偵測而無限制保存車主位置。

與主線案例銜接：假位置要經過哪些檢查

沿用 Day 17 的 Day17StatusMessage。SUMO 保存真實座標 truthX 與 truthY，OMNeT++ Payload 則帶有 claimedX 與 claimedY。惡意節點仍在道路上正常移動，只把宣告位置偏移 80 公尺。

接收端可以分層判斷：

1. 格式層確認欄位、長度與數值範圍
2. 安全層驗證 Sender 權限、簽章與 Freshness
3. 時空層計算連續訊息的速度及加速度是否合理
4. 地圖層確認宣告位置是否落在可行駛道路上
5. 證據層比較 SUMO Ground Truth、接收紀錄與交通反應

這裡使用 SUMO Ground Truth 是研究條件，量產車不會神奇地取得其他車輛的真實座標。真實系統只能使用本車感測、地圖、路側資訊與多個相對獨立來源形成信心。文章中的 80 公尺也只是實驗參數，不是通用安全門檻。

今日實作：建立可解釋的三層偵測紀錄

本實作限定在 Day 17 的 SUMO／OMNeT++ 隔離場景，不傳送到真實車輛或公共路側設備。

先為每筆接收訊息保存下列欄位：

simTime, receiverId, senderId, sequenceNumber,
claimedX, claimedY, truthX, truthY,
signatureValid, freshnessValid,
positionError, ratePerSecond, decision, reasonCode

接著依序套用三條教學規則：

Baseline 執行時保持 claimedPosition == truthPosition，確認規則不會因正常封包延遲而大量告警。Attack 執行只修改 Payload，不改 SUMO Mobility，再比較告警數、接收端採用率與後續減速事件。結果至少要能回答哪一條規則先觸發、觸發時使用哪些資料，以及防護是否改變交通結果。

規則的門檻必須和場景版本一起保存。若只留下 ALERT，後續無法判斷是攻擊、定位漂移、封包亂序，還是規則設定錯誤。

從偵測走到安全回應

偵測到單筆異常時，直接封鎖 Sender 未必安全。無線環境可能掉包，GNSS 也可能短暫漂移。較穩健的回應是先降低該資料的信任權重，要求跨來源佐證，並讓功能進入設計過的 Degraded Mode（降級模式）。

如果風險是大量異常訊息耗盡接收端資源，Gateway 可以先做頻率限制與佇列隔離。若診斷服務從不允許在行駛狀態跨入控制區，Gateway 應直接拒絕並留下原因碼。回應動作本身也要測試，避免安全控制成為新的阻斷服務入口。

把需求寫成「系統應安裝 IDS」太模糊。較可驗證的寫法是：

V2X 接收功能應在採用位置資料前檢查訊息新鮮度與時空合理性。檢查失敗時不得把該筆資料直接輸入自動控制決策，並應記錄規則版本、關聯訊息及處置結果。

這段文字定義了資料、時機、失敗行為與證據，後續才能設計測試。

CTF／CARsenal 支線：IDS 規則挑戰

主線概念：Identifier 頻率、週期、DLC 與跨區流量的異常偵測

工具環境：ICSim、vcan0、candump、cansniffer 與受限的 cangen

CTF 任務：先記錄 Baseline，再讓模擬節點產生有限測試流量，判斷哪一條 IDS 規則觸發

輸出證據：原始 CAN 紀錄、規則版本、觸發時間、Reason Code 與處置結果

所有流量限定在 vcan0 與 ICSim，不連接實體 CAN Bus

今日重點

• Authentication 證明受保護的來源與完整性，不證明宣告內容符合真實世界
• Secure Gateway 管理跨區資料流，Segmentation 限制入侵後的橫向移動
• IDS 告警是待調查證據，不是攻擊已成立的結論
• SUMO Ground Truth 要和 V2X 宣告值分開保存，才能量化欺騙與交通影響
• 防護要包含預防、偵測、降級、復原與可追溯紀錄
• 安全需求應描述觸發條件、處置與驗證證據

明日預告

今天的防線主要處理執行期間的資料流。車輛軟體本身若被換成未授權版本，再好的封包規則也可能被繞過。

Day 23 將分析 OTA、數位簽章、Secure Boot 與 Rollback Protection，追蹤一個更新套件從後端進入 ECU，再到下一次開機被信任的完整路徑。

參考資料

• NHTSA：Cybersecurity Best Practices for the Safety of Modern Vehicles（2022）
• AUTOSAR：Specification of Secure Onboard Communication，Classic Platform R24-11
• UNECE：UN Regulation No. 155 — Cyber Security and Cyber Security Management System
• ETSI：TS 103 759 V2.2.1 — Misbehaviour Reporting Service