Day 17 的兩台模擬車已經能互相廣播研究用訊息。
接收端只要收到 Day17StatusMessage，就會讀出 senderId、位置、速度與傳送時間，再把結果寫進 Log。
但目前的接收邏輯沒有確認三件事：
senderId 嗎？senderPosition 和 SUMO Ground Truth 一致嗎？這不代表我們已經找到一個真實車款的漏洞，卻清楚指出了一個需要分析的入口：外部節點可以把資料送進本車的 V2X Application。
把視野再拉遠，現代車輛還會從 CAN、診斷設備、Bluetooth、Wi-Fi、Cellular、V2X 與 OTA 更新流程接收資料。
每一條連線都可能帶來價值，也會讓新的元件、Parser、權限與信任邊界進入系統。
今天要做的不是宣判「聯網汽車不安全」，而是建立一套盤點方法，回答：攻擊者可能從哪裡接觸系統，資料會經過哪些元件，又要滿足哪些條件才可能形成攻擊路徑？
讀完這篇文章，你應該能夠：
只列出一台車有多少防護，或有多少外部介面，都不能直接回答「安全」或「不安全」。
較負責任的答案是：
車輛是否具有可接受的資安風險，要放回特定功能、架構、使用情境與生命週期評估，不能只靠介面名稱下結論。
同樣使用 Bluetooth 的兩套系統，可能採用不同晶片、Protocol Stack、配對政策與網路分區。
同樣具有 OBD-II 接口的兩台車，也可能有完全不同的 Gateway 規則與診斷權限。
即使某個版本目前沒有已知弱點，後續軟體更新、第三方元件與新研究仍可能改變風險狀態。
所以資安不是一次性的產品標章，而是一項持續的風險管理工作。
ISO/SAE 21434 將道路車輛 E/E 系統的資安工程延伸到概念、開發、生產、營運維護與除役，就是因為風險會隨生命週期改變。
今天先完成第一步：知道系統在哪裡接收外部輸入，以及這些輸入可能走到哪裡。
Day 01 已經分過攻擊面、弱點與攻擊路徑。
進入攻擊篇章前，再把常見的 Attack Vector 一起放進來：
| 名詞 | 本文使用方式 | 智慧十字路口例子 |
|---|---|---|
| 攻擊面 Attack Surface | 攻擊者可能接觸、呼叫或送入資料的介面及元件總和 | V2X Radio、訊息 Parser、憑證處理與接收端 Application |
| 弱點 Vulnerability | 設計、實作或設定中可能被利用的缺陷 | 例如 Parser 未正確檢查長度，或 Application 未檢查訊息新鮮度 |
| 攻擊向量 Attack Vector | 攻擊者用來接近入口或傳遞惡意輸入的方式 | 透過相容 Radio 傳送一筆特製或虛假 V2X 訊息 |
| 攻擊路徑 Attack Path | 從入口到目標資產的一連串已連接步驟 | 取得傳送能力 → 訊息被接收 → 檢查不足 → 錯誤資料進入警示邏輯 |
| 資產 Asset | 對利害關係人具有價值、需要保護的對象 | 位置資料、V2X 身分、警示判斷與車輛控制邊界 |
看見 Wi-Fi Service、Cellular Modem 或 OBD Connector，只能證明它們值得盤點。
要把入口寫成弱點，仍要確認特定版本與設定中存在可利用缺陷。
要把弱點寫成完整攻擊路徑，還要證明後續權限、Gateway 與目標 ECU 之間真的能接起來。
圖 1：攻擊面只是分析起點。弱點與跨越權限邊界的條件都要用證據確認，才能形成合理的攻擊路徑
2011 年的汽車攻擊面研究曾使用三種接觸範圍整理外部入口：間接實體、短距離無線與長距離無線。
這套分類到今天仍適合建立第一張地圖，但不能直接當成風險排名。
| 接觸範圍 | 常見入口 | 攻擊者需要的條件 | 分析重點 |
|---|---|---|---|
| 實體或間接實體 | OBD、USB、維修工具、外接裝置與供應鏈媒體 | 接近車輛，或讓受信任的人員及設備帶入資料 | 診斷權限、外接設備、惡意檔案與使用後是否移除 |
| 鄰近無線 | Bluetooth、Wi-Fi、V2X、NFC 與其他短距離 Radio | 位於通訊範圍，並滿足配對、關聯或協定條件 | 可發現性、認證、Parser、頻道負載與接收後隔離 |
| 遠端生態系 | Cellular、手機 App、後端 API、雲端服務與 OTA | 能到達服務、取得帳號或利用網路及後端弱點 | 車隊規模、憑證、API 授權、服務分區與事件回應 |
| 車內橫向路徑 | CAN、Automotive Ethernet、診斷路由與中央平台 | 通常要先取得車內節點或 Gateway 前方的能力 | 訊息過濾、來源驗證、最小權限與網路分區 |
「遠端」不必然等於高風險，「實體」也不必然等於低風險。
遠端入口可能具有較大的可達範圍，但仍可能受到網路隔離、憑證與後端授權限制。
實體入口需要接近車輛，成功後卻可能取得較高的診斷權限。
真正的比較還要加入攻擊可行性、權限、影響範圍、可偵測性與復原能力，不能只量距離。
把常見介面放回架構，可以看見它們通常不會直接連到致動器。
外部資料會先經過 IVI、TCU、OBU 或診斷入口，再跨越 Gateway 或中央平台，最後才可能進入車內網路與 ECU。
圖 2：攻擊面橫跨車外生態系、車輛入口與車內網路。箭頭表示需要檢查的資料流，不代表任一入口天然可以控制 ECU
這張圖最重要的是中間的 Gateway／中央平台。
如果 IVI、TCU 或 OBU 出現問題，分區與最小權限應限制它能接觸的網路、訊息與服務。
NHTSA 的現代車輛資安最佳實務也建議在網路區段之間使用強邊界控制，限制外部無線介面與安全關鍵系統之間的訊息流。
不過，Gateway 的存在不等於規則必然正確。
分析時仍要取得實際的 allowlist、診斷路由、服務權限與失效行為，才能知道邊界是否有效。
Day 03 到 Day 05 已經知道，Classical CAN 是共享的訊息導向網路。
基礎 CAN Frame 具有 CRC、ACK 與錯誤處理，卻沒有獨立的來源地址，也沒有替每筆應用訊息提供密碼學上的來源驗證及防重放。
因此，如果一個未受信任的節點已經取得某段 CAN 的傳送能力，接收 ECU 不能只靠 Identifier 判斷真正的發送者。
CAN 常見的分析問題包括：
但 CAN 往往位於車內，不一定是攻擊者最先接觸的入口。
較完整的假設路徑應寫成：
外部或實體入口
→ 某個 ECU／外接設備取得初始能力
→ 跨越 Gateway 或直接接觸目標 CAN 區段
→ 送出可被接收的 Frame
→ 目標 ECU 的應用邏輯採用資料
每一個箭頭都需要證據。
Day 19 會在 vcan／ICSim 中分析 CAN Injection，Day 20 再處理 Replay、DoS 與 Bus-Off。
今天不對真實車輛送出任何 Frame。
OBD-II 的 16-pin DLC 是最容易看見的車輛入口之一。
它讓合規的外部測試設備取得必要診斷資訊，也可能讓原廠或授權工具經 Gateway 到達更多 ECU。
盤點時不要把三件事混在一起：
| 層次 | 要確認的問題 |
|---|---|
| 實體接口 | 哪些 Pin 有接線？接口是否直接暴露診斷 CAN 或先進入 Gateway？ |
| 外接設備 | Scan Tool、Bluetooth／Wi-Fi Dongle 與維修電腦本身是否受管理及更新？ |
| 診斷權限 | 哪些 ECU、Session、Service 與 Security Level 可以從這個入口到達？ |
能讀取標準 OBD PID，不代表能執行 ECU Programming 或控制所有致動器。
反過來，介面需要實體接觸，也不能讓高權限服務省略授權與車輛狀態檢查。
長期插在車上的無線 OBD Dongle 還會把原本的實體入口擴展成持續存在的短距離或遠端入口。
這時攻擊面不只包含 DLC，還要加入 Dongle Firmware、配對方式、App、雲端服務與更新機制。
Bluetooth 常出現在 IVI、免持通話、音訊、手機 App 與數位鑰匙等情境。
它的攻擊面不是只有「PIN 安不安全」，而是整條資料處理鏈：
附近裝置
→ Radio 與 Bluetooth Controller
→ Protocol Stack／Profile
→ 配對、Bonding 與授權政策
→ IVI 或車輛 Application
→ Gateway 與其他車內服務
盤點時要問：
2011 年的第一手研究曾在特定測試車輛展示 Bluetooth 等外部介面的可利用弱點。
這項結果證明短距離無線入口值得分析，不代表現在所有車款或所有 Bluetooth 實作都有相同缺陷。
Wi-Fi 可能用於車內 Hotspot、手機投影、維修、資料同步或軟體更新。
同樣寫著 Wi-Fi，資料路徑可能完全不同：
車輛作為 Access Point
→ 手機或維修設備連進車輛提供的網路
車輛作為 Client
→ IVI／TCU 連到家用、維修廠或其他已設定網路
前者要盤點誰能加入網路，以及加入後能看見哪些 Port、Service 與其他 Client。
後者還要分析惡意或設定錯誤的 Access Point，是否能讓車輛連到不受信任的網路環境。
重要問題包括：
WPA 等無線鏈路保護只處理其中一層。
即使裝置合法加入 Wi-Fi，車上的 Application 與 API 仍要驗證輸入及操作權限。
TCU 可以透過 Cellular 連到緊急服務、車況回報、遠端控制、導航、車隊管理與 OTA 後端。
這條路徑的特別之處，是攻擊面跨出車輛本體：
手機 App／管理入口
→ 身分提供者與後端 API
→ 車廠或供應商服務
→ 行動網路
→ TCU
→ Gateway
→ 被允許的車內功能
分析不能只掃描 TCU 的 Network Port，還要盤點：
Cellular Modem 存在，不代表它能從公開 Internet 被任意連入。
實際可達性仍取決於電信網路、Private APN、Firewall、NAT、Service Binding 與後端架構。
不過，共用後端、軟體與憑證帶來的規模效應，仍讓這條路徑成為高價值的分析範圍。
Day 10 到 Day 12 已經建立 V2X 的信任邊界。
接收端可能持續處理附近車輛、RSU 與道路使用者裝置送來的狀態及事件訊息。
這裡至少有四類不同問題：
| 問題 | 例子 | 主要保護方向 |
|---|---|---|
| 格式安全 | 長度、版本或 ASN.1 欄位使 Parser 進入非預期狀態 | 嚴格解析、邊界檢查與錯誤隔離 |
| 來源與完整性 | 未獲授權的裝置偽裝成合法參與者 | 憑證、簽章、權限與信任鏈 |
| 新鮮度 | 舊位置或事件訊息被重新送出 | 時間、序列、事件版本與有效期間 |
| 內容合理性 | 持有有效憑證的故障或惡意節點宣告假位置 | Ground Truth、感測融合、地圖與行為合理性檢查 |
UN Regulation No. 155 的威脅與緩解清單，也把 V2X 假訊息、Sybil Attack、Replay、惡意內部訊息與惡意診斷訊息列入車輛通訊通道的分析範圍。
簽章可以保護來源與受保護內容的完整性，卻不能保證來源端的感測器與宣告內容符合真實道路。
Day 21 會再用位置欺騙、假訊息與 Sybil Attack 展開這一層。
OTA 是 Over-the-Air 的縮寫，描述軟體透過無線路徑發送到車輛的更新方式。
OTA 可能使用 Cellular 或 Wi-Fi 傳輸，但它不能和任一種 Radio 畫上等號。
完整更新鏈可能包含：
原始碼與 Build Pipeline
→ Release Approval
→ 簽章金鑰與 Metadata
→ Update Server／CDN
→ Cellular 或 Wi-Fi
→ TCU／Primary ECU
→ Target ECU 驗證與安裝
→ 版本確認、失敗復原與事件紀錄
每一個步驟都可能成為攻擊面。
盤點 OTA 時至少要確認：
NHTSA 的 2022 最佳實務要求維持 OTA 更新、伺服器、傳輸與整體流程的完整性，也提醒設計要考慮伺服器失守、內部人員、Man-in-the-Middle 與 Protocol Weakness。
更新功能同時是防護能力。
沒有可靠更新路徑，已知弱點可能長期留在車隊中。
Day 23 會把 OTA、Secure Boot、Rollback 與 Firmware Signature 再完整串起來。
| 攻擊面 | 典型可達範圍 | 第一個處理輸入的元件 | 最值得確認的邊界 |
|---|---|---|---|
| CAN | 車內網路區段 | CAN Controller 與 ECU Application | 未受信任節點如何取得傳送能力，訊息如何被驗證及採用？ |
| OBD／診斷 | 實體接觸，或經無線 Dongle 延伸 | Gateway、診斷 ECU 或外接設備 | 哪些 ECU、Session 與 Service 能從入口到達？ |
| Bluetooth | 鄰近無線 | Bluetooth Controller、Stack、Profile 與 IVI App | 配對後的權限，以及 IVI 和安全關鍵網路的隔離 |
| Wi-Fi | 鄰近網路，也可能連到既有基礎設施 | Access Point／Client、IP Stack 與 Network Service | 誰能加入網路，哪些 Port 與 Service 可見？ |
| Cellular／後端 | 遠端生態系 | Backend、TCU、Modem 與遠端控制 App | 帳號、API、車輛綁定、車隊規模與 Gateway 權限 |
| V2X | 附近直接通訊，或經網路型服務 | OBU、Security Layer、Parser 與 V2X App | 簽章驗證後，如何檢查新鮮度、合理性與相關性？ |
| OTA | 橫跨供應鏈、後端、Radio 與車內更新路由 | Build／Release、Server、TCU 與 Target ECU | 金鑰、映像、版本、安裝條件與失敗復原是否端到端受控？ |
這張表不是風險排名，也不是完整車輛清單。
數位鑰匙、USB、充電介面、GNSS、TPMS、行動 App、經銷商系統、開發工具與供應鏈元件，也可能是特定系統的重要攻擊面。
盤點必須依實際功能及架構更新，不能把七個名稱打勾後就宣布完成。
每一個入口至少回答以下問題：
| 欄位 | 要回答的問題 |
|---|---|
| 功能與使用情境 | 為什麼需要這條介面？車輛在什麼狀態下使用？ |
| 可達性 | 需要實體接觸、位於 Radio Range，還是能從後端遠端到達？ |
| 輸入 | 接收 Frame、Packet、File、API Command、Credential 還是 Firmware？ |
| 暴露元件 | 哪個 Chip、OS、Protocol Stack、Parser 或 Application 先處理輸入？ |
| 信任邊界 | 資料在哪裡從外部進入車輛，又在哪裡跨到其他網域？ |
| 資產 | 哪些資料、控制權、憑證、服務與操作紀錄需要保護？ |
| 現有控制 | 有哪些 Authentication、Authorization、Freshness、Filtering 與 Logging？ |
| 失效行為 | 輸入錯誤、服務中斷或憑證失效時，系統如何安全退化與復原？ |
| 證據 | 架構圖、版本、設定、測試結果與事件紀錄在哪裡？ |
| 待驗證假設 | 還缺哪一項資料，才能判斷弱點與攻擊路徑是否成立？ |
攻擊面清冊的價值，不是讓表格看起來很滿。
它要讓下一位分析者知道哪一項是已確認事實，哪一項是待測試假設，以及結論使用哪一份版本與證據。
假設一台車提供 Wi-Fi Hotspot，我們可以先提出一條教學用路徑：
附近攻擊者能加入 Wi-Fi
→ 看見 IVI 的某項 Network Service
→ 該 Service 存在可利用弱點
→ 攻擊者取得 IVI 中的初始能力
→ Gateway 規則允許不必要的跨網域訊息
→ Body ECU 採用未授權資料
→ 車身功能或使用者資料受到影響
這不是漏洞報告，而是一組要逐項查證的假設。
至少要確認：
只證明前兩項，不能直接跳到「能控制車輛」。
同樣地，只證明最後的 CAN 訊息可以改變測試台狀態，也不能自動證明遠端攻擊者有辦法走完整條路。
風險判斷至少還要加入：
這些因素會在 Day 24 到 Day 29 的 ISO/SAE 21434 與 TARA 再用一致的方法評估。
今天不要急著替每個入口打出一個風險分數。
先把系統邊界、資料流、資產與證據整理正確，後面的 Threat Scenario 與 Attack Path 才不會建立在錯誤架構上。
一條外部路徑不應只依賴最外層的配對密碼或 Firewall。
合理的多層防護可能包含：
減少不必要介面與服務
→ 外部身分驗證及最小授權
→ Parser 與輸入驗證
→ Gateway allowlist 與網路分區
→ ECU 端再次檢查狀態、權限與新鮮度
→ Event Log、異常偵測與事件回應
→ 安全退化、更新與復原
每一層處理的問題不同。
例如 Wi-Fi Authentication 不能取代 Application Authorization，Gateway Filtering 也不能取代 Target ECU 對高風險操作的條件檢查。
Day 22 會再介紹 IDS、Secure Gateway、Authentication 與 Segmentation。
Day 23 則處理 OTA 與 Secure Boot，讓更新與啟動流程成為可持續的防線。
今天不新增攻擊程式，也不修改 Day17V2XApp。
我們直接使用 Day 17 已經留下的 NED、C++、Message、SUMO 場景與 Log，完成一張可以驗證的攻擊面卡片。
系統範圍
→ Day 17 的兩台 SUMO Vehicle 與 Veins Vehicle Node
分析功能
→ 週期廣播並接收 Day17StatusMessage
不在範圍內
→ 真實 Radio、標準 BSM／CAM、PKI、實車 Gateway 與道路車輛
這一步可以避免把模擬中的研究用 Message 誤寫成真實產品弱點。
| 欄位 | Day 17 的已知事實 |
|---|---|
| 入口 | Veins IEEE 802.11p／WAVE 教學模型中的無線接收路徑 |
| 外部輸入 | Day17StatusMessage，包含 senderId、序號、位置、速度與傳送時間 |
| 第一個應用處理點 | Receiver 的 Day17V2XApp::onWSM() |
| 資料流 | Sender App → MAC／PHY → Wireless Channel → Receiver MAC／PHY → onWSM() |
| Ground Truth | SUMO／TraCI 提供的 Vehicle Position 與 Speed |
| 主要資產 | Ground Truth、宣告位置、Sender Identity、接收結果與警示邏輯的可信輸入 |
| 現有證據 | SEND／RECV Log、day17Sent、day17Received 與 receptionDelay Vector |
Day 17 已經明確列出：Message 沒有憑證、簽章與完整防重放機制，接收端也沒有比較宣告位置和 Ground Truth。
因此可以建立以下假設：
| 待驗證假設 | 還需要的安全模擬證據 |
|---|---|
節點可以宣告另一個 senderId |
在隔離模擬中讓 Payload Identity 和 Physical Node 映射不同，再確認接收端如何處理 |
| 節點可以宣告錯誤位置 | 保留 SUMO Ground Truth，只修改 Payload Position，記錄兩者差值 |
| 舊訊息可能被再次接受 | 定義 Replay Cache 與時間窗，再比較重送前後的接收結果 |
| 高頻訊息可能增加頻道或接收端負擔 | 固定車流及 Radio Model，只調整 Message Rate 並量測 Channel 與 Application Result |
這些仍是模擬研究假設，不代表任何特定量產車存在相同弱點。
Baseline
→ Payload Position = SUMO Ground Truth
Attack
→ 只修改惡意節點的 Payload Position
→ SUMO Ground Truth、Route、Seed 與 Radio Model 保持不變
Mitigation
→ 在相同 Attack 上加入 Freshness／Plausibility Check
→ 比較接受、拒絕與交通反應
今天只完成設計與清冊，不執行 Attack Run。
Day 21 會實作假位置與 Sybil 情境，Day 22 再加入偵測及限制，最後在 Day 30 把證據送進 TARA。
一份合格的 Day 18 清冊應該能回答：
安全與法律提醒： 本篇只進行架構盤點與隔離模擬設計。後續所有訊息修改、注入與重放都限定在
vcan、ICSim、SUMO／OMNeT++、隔離測試台或明確取得授權的設備，不對道路車輛、他人的 OBD 介面、公共 RSU 或未授權網路進行測試。
今天已經知道 CAN 常位於攻擊路徑的車內階段，也知道 Identifier 本身不能證明真正發送者。
Day 19 將進入隔離的 vcan／ICSim 環境，分析 CAN Injection：未受信任的節點取得傳送能力後，如何偽造格式正確的車載訊息，以及 Gateway 與應用層為什麼不能只相信 CAN ID。
iThome鐵人賽
看影片追技術