AUTOSARの最新動向：2016年3月版：AUTOSAR〜はじめの一歩、そしてその未来（7）（1/3 ページ）

筆者へのAUTOSAR関連の問い合わせで、最近になって急激に増えているトピックが幾つかある。今回はそれらのトピックをまとめる形で、「AUTOSARの最新動向：2016年3月版」と題してお送りしよう。

[櫻井剛（イータス RTAソリューション シニア・コンサルタント），MONOist]

　これまで、マネジメント面の話ばかりが続いてきたので、今回は少々技術面にも踏み込みたい。そこで、以下に挙げるような「AUTOSAR関連で最近急にお問い合わせが増えたトピック」をまとめる形で「AUTOSARの最新動向：2016年3月版」と題してお送りする。

1. CAN通信におけるセキュリティ対策手法の動向
2. 通信路における安全・セキュリティ対策
3. AUTOSAR Adaptive Platform（AP）／AUTOSAR Foundation（AF）
4. 自己診断系のBSWの入手性

　なお、前回予告していた、「量産開発を通じてのAUTOSAR導入」の2つ目の側面である「AUTOSAR導入により、基本的な型や支援体制をどのように変えていくかの見極めと必要な活動の実施」についての「再利用」をキーワードとした解説は、次回の掲載をお待ちいただきたい。

CAN通信におけるセキュリティ対策手法の動向^※1）

　AUTOSAR規格（CP R4.2.2）におけるSecure Onboard Communication（SecOC）モジュールは、カウンタとメッセージ認証コードによるメッセージ認証を想定している（図1）。

図1　AUTOSAR SecOCにおけるメッセージ認証 （クリックで拡大） 出典：AUTOSAR CP R4.2.2 SWS SeoOC

　SWS SecOC sec. 4.1には、「The SecOC module is restricted to only provide the IF API towards the upper layer. Thus, the authentication of PDUs from and to DCM/J1939DCM is currently not supported.」と記載があり、現時点では、診断通信（diagnostic communication）をSecOCではカバーしないことが明記されている^※2）。また、NM（network management）やXCPのメッセージについては、関連するCanNmやXcpモジュールはPduRを介さずにCanIfから直接情報を受け取る構造であることから、PduRを介することを構造上の前提としているSecOCではカバーできない（図2）。通信プロトコルに関しても、LINとMOSTを想定しないことが明示されている（同sec. 4.2）。

図2　AUTOSAR SecOCと他のBSWとの構造面の関係（クリックで拡大） 出典：AUTOSAR CP R4.2.2 SWS SeoOCのFigure 1に筆者追記

　CAN通信（最大データ長64ビット、CAN FDにも対応したISO 11898-1:2015では「Classical CAN」と表現）のセキュリティ対策としては、通信路の暗号化ではなく、メッセージ認証コード（MAC：Message Authentication Code）が主流と考えられている。SecOCでも暗号化は想定していない。

　暗号化が主流とならないと考える理由としては、例えば以下を挙げることができる。

1）暗号の強度

　この規模のデータ向けの暗号方式としては、共通鍵のブロック暗号方式の1つであるData Encryption Standard（DES）が古くから使われてきた^※3）。

　ブロック暗号には、同じ鍵と同じ平文の組み合わせに対し、同じ暗号文が得られるという性質がある。周期送信のように同じ値が繰返し送信されることが多いような状況においては、これは弱点となる。

　その弱点を補うために、例えば、平文のスペース割り当てを削りカウンタを付加し、同じ暗号文が送信される周期を少しでも長くするという措置が考えられるが、通信路の利用効率を考慮するとカウンタ長を大きくすることは難しい。カウンタ長が短ければ、同一の暗号文が現れる周期も短くなるため、暗号の強度は弱くなる。

　また、そもそも鍵長が短ければ総当り攻撃に弱い。DESの実質的な鍵長は56ビットと短く、それが理由でAESに置き換えられたという経緯もある^※4）。

　なお、DESの暗号化を3段繰り返す方式であるTriple DES（3DES）も存在するが、処理時間は3倍に増大し、一般にはAESよりも計算量が多くなる。

2）通信データの用途の多様性

　平文データに対してMACや誤り検出コードが付加されているメッセージであっても、safety criticalでもsecurity sensitiveでもない受信側ECUでは、付加されたコードを無視して平文データのみを参照し利用するといった使い方が可能である。

　しかし、暗号化されてしまうと、復号しなければ平文データが得られないため、全ての受信側ECUで復号処理を行わなければならず、処理コストが増大する（この場合のコスト増大は、マイコン性能向上のための部品の金銭コスト増大や、復号処理のための時間コストの増大またはその組み合わせ）。

　通信路に送出される同一の情報は、複数の異なる用途で使用される可能性がある^※5）。特に、ユニキャスト方式ではなくCANのようなマルチキャスト方式の伝送の場合には、その用途（context）の多様性を積極的に利用する場合もある。

　現在も小規模マイコン（8ビットや16ビット）を採用するECUは少なくないため、一律に暗号化を適用することを決める前には、暗号化によるトレードオフに対する十分な分析と評価を行い、必要な対処を特定することが必要である。

注釈

※1）本節は、イータス株式会社／ESCRYPTのCamille Vuillaume氏の協力による。詳細については、必要に応じて別途お問い合わせください。

※2）ただし、ISO 14229-1 UDS ServiceのSID 0x27 SecurityAccessでunlock状態に遷移した後でのなりすまし（masquerading）の脆弱性は既知であり、今後何らかの対処の必要性が検討されるものと予想される。

※3）なお、ここで示したDESそのものには誤り検出の能力はない。誤り検出をさせようとする場合には、平文を削り固定データパターンを付加し、復号後に得られた固定データパターンの照合を行うといった方法が考えられるが、通信路の利用効率を考慮すると固定データパターン長を大きくすることは難しい。しかも、このような使用方法での誤り検出能力はCRCに比べて劣る（固定データパターンに現れない誤りなど）。また、固定データパターン長が短くなれば、その部分で誤りを検出できる可能性はより低下する。また、同一メッセージの繰り返し送信（repetition）が続いた場合の検出についてもDESでは検出できない。平文を削りカウンタを付加するなどの措置が必要となる。

※4）なお、2013年、NSAは新たな暗号化方式としてSimonおよびSpeckを公表した。しかし、一般には10年程度の評価を経てから市場に投入されるのが通例であり、現状ではその地位が確立されているとはいえない。

※5）IEC 61508からも通信面に関して参照されているIEC 62280 Ed.2 (2014) clause 7.2.2では、安全関連系と非安全関連系の分離を要求しているが、車両で使用されるCANにおいては、メッセージID空間（資源の一種）の制約から、安全関連と非安全関連のメッセージの分離は容易ではないとも考えられている。現実には検査用の情報を無視する、あるいは全てを安全関連のものにまとめるなどの対処が取られている。セキュリティ面でも同様な議論となるであろう。