バックナンバーはこちら。
https://www.simulationroom999.com/blog/diagnostic-communication-backnumber/
はじめに
ISO14229ことUDSの話。
SecurityAccessサービスの基本フローについて。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
SecurityAccessサービスの基本フロー
じゃー今回こそSecurityAccessサービスの基本フローやるよー。
前回もそんな感じのくだりから始まった割にはやらなかたたね。
いやー、
車両診断通信にセキュリティ文化の話でまぁまぁのボリュームになっちゃったからねー。
まぁわからんでもない。
(教えてもらう側の態度じゃないんだよなぁ)
前回、太郎くんがなんとなく気づいたと思うけど、
以下の流れになるよ。
①DiagnosticSessionControlサービスでextendedDiagnosticSessionに遷移
②SecurityAccessサービス requestSeedでSeed取得
③SecurityAccessサービス sendKeyでKey送信
うん。僕も前回の話を聞いてこのイメージになった。
SecurityAccessサービスの基本フロー(実際のメッセージ)
じゃ、実際の具体的なメッセージを書いていこう。
待ってましたー。
とりあえず、コメント付きでざっと電文を書くよ。
Req: 0x10 0x03 // extendedDiagnosticSessionへ遷移要求
Res: 0x50 0x03 0x03 0xE8 0x13 0x88 // P2時間:1秒、P2*時間5秒
Req: 0x27 0x01 // SecurityAccessサービス requestSeed Level1
Res: 0x67 0x01 0x12 0x34 // Seed = 0x1234
Req：0x27 0x02 0x56 0x78 // SecurityAccessサービス sendKey Level1 Key=0x5678
Res: 0x67 0x02
ちなみにSeedからオフボードテスタとECUで共通のハッシュ関数を通して双方Keyを生成する。
このKeyが一致してたらセキュリティアンロックとなる。
なるほど。
なんとなくイメージ通りだ。
ところでLevel1ってなに？
セキュリティレベルだね。
SecurityAccessサービスのsub-functionは
奇数がrequestSeed で、
偶数がsendKeyってのはやったと思うけど、
0x01と0x02が対でLevel1
0x03と0x04が対でLevel2
…
0x21と0x22が対でLevel17
って感じ。
Levelが上の方が上位ってイメージ？
そこは完成車メーカ側のコンセプト次第かなー。
基本的には上位のLevelが下位を内包という考え方はあるようだけども、
必ずそうだとも言い切れない感じだね。
まぁ、そこらへんはいろいろ都合がありそうだもんだねー。
で、Levelに応じて使用できるサービスが変わるってことであってる？
そうだね。
厳密には使用できるリソースかな？
リソースには
- サービス
- DID
が含まれていて、
Serivce$22の特定DIDだけはセキュリティ解除されていないと使用できないというような構成も作れる。
うーん、セッションがあったり、セキュリティがあったり、リソースがあったりでややこしいなー。
ここらへんは追々慣れていくしかないかなー。
まとめ
まとめだよ。
- SecurityAccessサービスの基本フローを説明。
- SecurityAccessサービスの基本フローに於ける実際のメッセージを説明。
- セキュリティが掛かるのはリソース。
- サービス。
- DID。
バックナンバーはこちら。
コメント