寫組態、刷韌體、跑危險例程——這些操作前，ECU 都會先問一句：「你有權限嗎？」問這句話的就是 0x27 SecurityAccess。它是一套挑戰—回應機制，也是診斷測試裡邊界條件最多、最值得自動化的一個服務。
本文是 UDS 是什麼 的深入篇；它與資安機制（SecOC 與 E2E）的分工是：$27 管「診斷通道的存取權」，SecOC 管「匯流排訊息的真實性」。
四步流程：種子—金鑰
- 測試端請求種子：
27 01（子功能 0x01，requestSeed） - ECU 回一組隨機種子：
67 01 <seed> - 測試端用保密演算法把種子算成金鑰送回：
27 02 <key>（子功能 0x02，sendKey） - ECU 用同樣的演算法驗證，通過就解鎖：
67 02
奇偶數的規則值得記：奇數子功能請求種子（0x01、0x03…），偶數送金鑰（0x02、0x04…），相鄰的一對奇偶數對應一個安全等級。所以一顆 ECU 可以有多個安全等級——例如 0x01/0x02 解鎖一般寫入、0x11/0x12 解鎖刷寫，各自的金鑰演算法與權限範圍不同。
一個常被誤解的細節：如果請求種子時 ECU 回全零種子，通常代表「這個等級目前已經解鎖了」——不是出錯，是省略後續步驟。
防暴力破解：延遲與鎖定
種子—金鑰若能無限次嘗試，攻擊者暴力試金鑰只是時間問題。所以 $27 內建三道防線，也是測試的重災區：
| 機制 | 行為 | 對應 NRC |
|---|---|---|
| 嘗試次數限制 | 連續錯 N 次金鑰後鎖定 | 0x36 exceededNumberOfAttempts |
| 延遲計時（Delay Timer） | 鎖定後強制等待一段時間才能再試 | 0x37 requiredTimeDelayNotExpired |
| 開機保護 | 有些實作要求 ECU 剛開機的一小段時間內拒絕安全存取 | 0x22 conditionsNotCorrect |
延遲計時還有個容易踩的規則：延遲期間即使送對金鑰也會被拒，而且錯誤的嘗試會重置計時。測試若沒覆蓋這條，實車上會出現「密碼明明對卻進不去」的靈異現象——其實是還在罰站。
為什麼種子每次都要不一樣
種子必須是足夠隨機、每次不同的。若種子固定或可預測，攻擊者錄一次合法的「種子—金鑰」配對就能重放——這在資安審查（見 TARA 怎麼做）裡是必查項。種子的隨機性、金鑰演算法的強度、以及演算法本身怎麼保護（不能寫死在容易被讀出的地方），構成 $27 的資安評估三角。
測試清單：正向少、反向多
$27 的測試價值幾乎都在反向案例：
正向（少）
- 正確種子—金鑰流程，各安全等級都解鎖
- 解鎖後對應等級的操作確實放行
反向（多，才是重點）
- 錯誤金鑰 → 0x35 invalidKey，計數器加一
- 連錯達門檻 → 0x36 鎖定
- 鎖定期間再試 → 0x37，且錯誤嘗試重置計時
- 跳過種子直接送金鑰 → 0x24 requestSequenceError
- 開機保護期內請求 → 0x22
- 解鎖後切換會話／逾時 → 權限是否正確失效
- 種子隨機性：多次請求種子不應重複或可預測
「解鎖後權限何時失效」特別容易漏：切換診斷會話、0x3E TesterPresent 斷掉逾時、0x11 ECUReset 之後——這些邊界的權限重置行為，是產線與售後安全的最後一道防線。
一顆 ECU 多個安全等級 × 每個等級一套正反向 × 各種邊界時序，人工測不完也測不準——這是 $27 測試必須自動化（如 CANoe.DiVa 由診斷規格生成）的直接理由。
下一步
從安全存取的等級設計、演算法評估到自動化攻防測試，歐特莫夫（Vector Informatik 合作夥伴）協助把診斷安全建成可驗證、可稽核的證據。
- 📄 解決方案：UDS 功能設計與驗證、車用資安 ISO/SAE 21434
- 📬 預約一次現況盤點