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

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

通信路における安全・セキュリティ対策

　機能を車両レベルで見ると、「制御システムを複数に分割したとき、そこに通信路が現れる」と考えることができる（図3）。

図3　システム分割により現れる通信路（クリックで拡大） 出典：筆者作成

　通信路における安全やセキュリティの対策に関する議論で極めて重要になるのは、通信路の設計面の再整理である（保護・暗号化すべき伝送とそうではないものの区別など）。

　ISO/IEC Guide 51：2014が要求する、製造者側でのリスク低減における3ステップメソッド（three-step method）の原則は以下の通りである。なお、順序を入れ替えてはならない(clause 6.3.5)。

• Step-1：本質的安全設計方策(inherently safe design)
• Step-2：安全防護及び付加保護方策(guards and protective devices)
• Step-3：使用上の情報(information for use)

　これを通信路の設計に当てはめると、分割位置を変えることによる本質的安全設計の達成と、分割位置を変えずに保護方策（E2EやSecOCなど）を適用するのとでは、前者が優先されることが明らかである。

　現実には、分割位置の変更は既存ECUとの互換性を損ねる（通信マトリクス仕様を変更する）ことになるため、その兼ね合いが問題になることが非常に多い。しかし、いきなり安全性よりも互換性（経済性）を優先するのは、原則論からもまた倫理の観点からも適切ではない。

　また、「今は変えることはできない」のであれば、次回の変更の機会においても同様に「今度も変えることはできない」という繰り返しが起こりかねない。少なくとも、以下のようなことを行わないのであれば、PL問題が生じた場合などに倫理面からの追及に耐えるのは難しいであろう。

• Step-1を採用不能と判断した根拠、過程と判断の責任の所在を記録（ISO 26262-2:2011 clause 5.4.2／Annex B 安全文化）
• かつ、Step-2を検討し、残存リスク情報を後工程／ユーザーに明示的に引き渡し（＝Step-3）
• かつ、Step-1採用のための中長期計画を立案、担当アサインし発動（いつまでも、「今は変えられない」を続けないために「変更計画を立案し発動」）（ISO 26262-2:2011 clause 5.4.2.4 逸脱状態解決プロセス要求）

　さらに別の側面からも再整理の重要性を説明することができる。AUTOSARについてここでは特に詳細を述べないが、その導入の主な動機の1つであるソフトウェア開発工数の抑制（特にアプリケーション面）においては、インタフェースを継続的かつ積極的に再整理し見直し続けるという管理により、バリアントやブランチの発生を抑制し続けるというマネジメントが必要になる（図4の矢印3による効果の部分）。

　しかし、ソフトウェアコンポーネント（SW-C）間のインタフェースは、ECU内通信となる場合もあれば、ECU間通信となる場合もある。従って、通信路の設計面の再整理や継続的な見直しは、ECUに搭載されるSW-Cのインタフェースの管理にも直結する^※6）。

図4　AUTOSAR導入後による効果（クリックで拡大） 出典：筆者作成

　また、例えば、「暗号化はいつか必要になるだろう、だから今暗号化を適用しておけば、しばらくの間はしのぐことができるのではないか」と想定し、分析に基づかずに技法にのみ注目するのは、近年の安全分野での主流であるリスクベースのアプローチに反する。「定義、分析、評価／判断／意思決定、対応／実施／実装」の流れと、リスク低減における3ステップメソッドに従い、safety criticalあるいはsecurity sensitiveな情報が通信路に現れないような設計（Step-1）の可能性を十分にしてから、通信路の保護（Step-2）の手段を検討するのが適切な対応といえるであろう。

　少なくとも、目的をはっきりさせずに暗号化技術やメカニズムを導入しようとすることは避けるべきだ。もし、攻撃者（attacker）による攻撃の意図が、自動車産業における対応コストの上昇、あるいは他に対応が必要な部分へのリソースなどの割り当て抑制のような戦力分散を狙った戦術であれば、それは攻撃の成功そのものであるからだ。

　加えて、セキュリティ分野の進歩のスピードは安全分野のそれよりもより速く、ある時点での対策が長期にわたり有効となる保証はない。「寿命」に対する考慮は不可欠である。

　もちろん、技法の議論も重要であるし、その重要性を否定するつもりはない。しかし、それ以前に行うべき議論の必要性を無視してはならない。

注釈

※6）自動車メーカーにおいてこれらを担当する部門を、筆者は「ライブラリアン」（librarian）と仮称している。それなりの規模と権限を与えられた上での、ライブラリアン部門（あるいはE／Eアーキテクチャ管理部門）によるこういった管理業務は、今後の開発を持続可能なものとするためには極めて重要であると考える。再利用可能な設計資産の管理の1つには、SW-Cが利用可能なインタフェースの定義であるPort Interfaceのライブラリ管理が挙げられる。これを怠ると、C言語における識別子の名前空間での問題、例えば、競合問題や類似のものが生まれることをいかに抑制し一本化するかというような問題が発生する。管理対象の複雑化が進むことにより、ライブラリ管理の重要性は急速に高まるはずであり、専属のライブラリ管理者＝ライブラリアンの設置も検討する必要があるかもしれない。

　また、再利用体制の確立、維持運用のためには、その推進者に対して「再利用の機会を確保する」ための十分な社内権限も与えられる必要がある。

　なお、AUTOSAR Open Conferenceなどの交流の場における非公式コミュニケーションで、このような管理業務を、それなりの規模と権限の裏付けのもとに古くから取り組んでいる欧州自動車メーカーが複数存在することを確認している。しかし、国内では極めて小規模の活動として行われており、実質的に単一の技術者に依存していることも少なくない。これは、経営上の大きなリスクであるはずだが、その認知はまだ十分ではない。