34
協調システ 協調システ 協調システ 協調システ 1テム並びに周辺のセキュリテ テム並びに周辺のセキュリテ テム並びに周辺のセキュリテ テム並びに周辺のセキュリテ 付録2 ティ ティ ティ ティ

協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

Embed Size (px)

Citation preview

Page 1: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

協調システム並びに周辺のセキュリティ協調システム並びに周辺のセキュリティ協調システム並びに周辺のセキュリティ協調システム並びに周辺のセキュリティ

-1-

協調システム並びに周辺のセキュリティ協調システム並びに周辺のセキュリティ協調システム並びに周辺のセキュリティ協調システム並びに周辺のセキュリティ

付録2

協調システム並びに周辺のセキュリティ協調システム並びに周辺のセキュリティ協調システム並びに周辺のセキュリティ協調システム並びに周辺のセキュリティ

Page 2: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-2-

Page 3: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-3-

第 1 章 自動車をめぐるセキュリティ

協調ITSの実用化を控え、V2X通信のセキュリティ確保に関する動きが活発化している。

この一方で、スマートフォン等のCE(Consumer Electronics)デバイスを介した自動車と外

部の接続も活発化しており(図1-1~2)、自動車全体のセキュリティを議論する必要性も指

摘され、こうした検討の動きも活発化している。そこで、ここでは、まず、自動車をめぐ

るセキュリティ全般について記述し、次いで、協調システムにおけるセキュリティの動向

を報告する。

(出典) IPA 自動車情報セキュリティへの取り組みガイド、2013年) 図1-1 自動車システムを取り巻く環境

(出典:Dieterich, Escar 2012基調講演) 図1-2 増加する自動車のインターネットへの関わり

Page 4: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-4-

(1) 自動車全般のセキュリティ検討

自動車全般に関するセキュリティの検討は、独立行政法人 情報処理推進機構(以下、IPA

と略す)が2007年~2012年まで、継続的に検討し、報告書を発行している。メーカ、車種

毎に多様な自動車内のネットワークの構成をモデル化したIPAカーを提案し、このモデル

に対するセキュリティ脅威を検討している(表1-1)。

表1-1 自動車に対するセキュリティ脅威の例

(出典) IPA 自動車情報セキュリティへの取り組みガイド、2013年)

IPAでは、自動車の車載LANを基本制御機能(エンジン等の駆動系)、拡張機能(ボディ

系、安全快適機能、診断保守等の制御関連、インフォテイメント、テレマティックス、ITS

機能等の情報関連)に分け、それぞれについてリスク分析を実施している(図1-3)。

Page 5: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-5-

(出典) IPA 自動車情報セキュリティへの取り組みガイド、2013年)

図1-3 IPAカーの構成

(2) 自動車内のセキュリティ対策

前述の脅威への対策として、取られるセキュリティ対策の例を以下に示す。

① 暗号化

通信される情報を暗号化し、容易に解読出来ないようにすることで、盗聴、通信される

情報の盗難を防ぐ。暗号化では、情報を暗号にする際と、暗号化された情報から元の情報

を復号する際に鍵を用いる。暗号化と復号に共通の鍵を使う仕組みを共通鍵暗号という。

鍵が知られてしまうと役に立たなくなるため、秘密にする必要があり、秘密鍵暗号方式と

も呼ばれる。また、暗号化、復号に同じ鍵を使うことから対称鍵暗号とも呼ばれる。

これに対して、暗号化に共通の鍵を使う仕組みを共通鍵暗号と呼ぶ。復号には、共通鍵

と同時に生成した秘密鍵を使う。公開鍵暗号方式とも呼ばれる。受信者が、公開鍵と秘密

鍵をペアーで生成し、公開鍵を送信側に公開し、これで暗号化してもらう。この鍵で暗号

化された情報を復号できるのは、秘密鍵を持っている者だけであること、公開鍵から秘密

鍵を推測することは困難であることを原理としている。代表的な暗号方式に、RSA(発明

者の名前の頭文字を取って命名)暗号がある。これは、大きな数の素数の掛け算で出来た

数の素因数分解が困難であることを根拠にしている。この他、楕円曲線暗号という方式も

ある。

② 認証

情報通信において、通信する相手、あるいは通信される情報を確認する手段である。ID/

パスワードを用いたり、証明書を添付したりする。公開鍵インフラ(PKI)では、この内、

信頼できる第3者に公開証明書と署名を預けておくことで、署名を確認することで証明書が

信頼でき、情報が信頼できることになるとしている。

Page 6: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-6-

③アクセス制御

利用者の実行権限や機能、通信の実行範囲の管理をすることでセキュリティを確保する。

こうしたセキュリティ管理は、自動車が使われている間だけでなく、図1-4に示すように、

自動車の企画・製造から、廃棄に関わる全ての過程にセキュリティの視点からの対策が求

められる。とりわけ、利用後の自動車には、鍵を含むセキュリティ関連機器が含まれてい

るため、適切な処置が必要となる。

(出典) IPA 自動車情報セキュリティへの取り組みガイド、2013年)

図1-4 自動車の運用サイクル

(3) 車外のセキュリティ対策

これまでは、主に自動車の中の情報セキュリティに関して紹介したが、協調システムで

は、車外のシステムも影響する。こうした点に着目した報告を次に紹介する。

2013年10月に東京で開催されたITS世界会議では、SIS(Special Interest Session;特別テ

ーマのセッション)でセキュリティが取り上げられ、V2X通信を中心に、関連したセキュ

リティに関して報告が行われている。ここでは、自動車の内部、周辺車両との通信に限ら

ず、例えば、GPSとの通信、路側機器との通信についても、セキュリティ上の配慮が必要

であると指摘している(図1-5)。

Page 7: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-7-

(出典)Leinmuller、 ITS世界会議2013 SIS66資料)

図1-5 V2X 協調システムのセキュリティ脅威要因

自動車環境に対して、セキュリティ対策と対処できる/できない事項についても表1-2の

ように整理されている。

表1-2 自動車に装備するセキュリティ機能と対応できる脅威

セキュリティ機能

対応する脅威・防御対象

車両追跡 成りすまし

情報

重 要 情 報

(証明書、 暗号鍵)

V2Xシステム センサ情報

証明書なしの仮名 ○ 仮名+ 証明書付きのソフトウェア セキュリティ

○ ○

上記+ ハードウェアセキュリティ (セキュアな格納、処理)

○ ○ ○

上記+ V2Xサブシステム全体のハ

ードウェアセキュリティ ○ ○ ○ ○

上記+ V2Xに情報提供する全ての

車載ネットワークのハード

ウェア(セキュリティ)

○ ○ ○ ○ ○

(出典)Leinmuller、 ITS世界会議2013 SIS66資料よりJARI編集)

また、通信相手をどの程度信頼できるかを測る指標としてTAL(Trust Assurance Level;信

頼保証レベル)が提案されている(図1-6、図1-7)。これは、V2Xシステムの構成に対して、

セキュリティの共通評価基準であるコモンクライテリア(CC,ISO/IEC 61508)に基づく

評価基準EAL(Evaluation Assurance Level)と最低限のセキュリティ機能を要件として規定

し、それらに対して、セキュリティ攻撃に対する耐性、C2X(V2X)通信のユースケース

例を、評価基準と共にまとめたものである。この報告の中では、V2X通信における最小限

の要件はTAL2(V2X;ハードウェア、EAL 4、専用ハードウェアセキュリティ対策(セキ

Page 8: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-8-

ュアなメモリ、CPU、タンパ証跡)であるとしている。表1-3にコモンクライテリア

(ISO/IEC61508)に規定される評価基準EALを示す。

(出典)2013年C2C-CC ワークショッププレゼン資料

図1-6 信頼保証レベルの概念

(2012年 C2C-CC ワークショップ S.Goetzプレゼン資料)

図1-7 信頼保証レベルの考慮範囲案

Page 9: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-9-

表1-3 コモンクライテリアに規定される評価保証レベル

レベル 内容 EAL1 評価保証レベル1 機能テスト functionally tested EAL2 評価保証レベル2 構造テスト structurally tested EAL3 評価保証レベル3 方式テスト、

及びチェック

methodically tested and checked

EAL4 評価保証レベル4 方式設計、テスト、 及びレビュー

methodically designed, tested and reviewed

EAL5 評価保証レベル5 準形式的設計、 及びテスト

semiformally designed and tested

EAL6 評価保証レベル6 準形式的検証済み設計、 及びテスト

semiformally verified designed and tested

EAL7

評価保証レベル7

形式的検証済み設計、 及びテスト

formally verified designed and tested

(出典)コモンクライテリア パート3:セキュリティ保証コンポーネントバージョン3.1 改訂第 4 版〔翻訳第1.0 版〕(2012年11月26日掲載) 及びCommon Criteria for Information Technology Security Evaluation,Part 3: Security assurance components Version 3.1 Revision 4

ドイツの自動車部品大手Robert Boschは、第10回Escar(Embedded Security for Car;車載

組込みシステムのセキュリティ会議)(2012)において、自動車のセキュリティ対策をV2X、

車載ネットワーク、ECUに分けて紹介している。この中で、ECUに関しては、重要な物に

はハードウェアセキュリティモジュールを搭載する予定であることを明らかにしている。

またV2X通信については、現在大規模実証中としている。車載ネットワークについては、

検討中としている(図1-8)。

(出典)Dieterich,Escar2012基調講演

図1-8 自動車セキュリティ検討例

以上、協調システムを含む自動車関連セキュリティに関する検討は、個別の検討から次

第に自動車を含む全体システムを対象にして検討する方向に移行しつつあると言える。

Page 10: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-10-

第2章 協調システムにおけるV2X通信セキュリティの動向

本章では、協調システムにおけるV2X通信に関するセキュリティの仕組みについて、欧

米で実施中の状況を報告する。欧州では、EC委員会のITS標準化指令M/453に対する報告書

が提出され、各地でFOTが実施されている。北米でも、ミシガン州で3000台近くの車両に

V2Xシステムを搭載したFOTが1年半に亘って実施された。この中で、セキュリティ管理の

ためのPKIの運用上の課題検討も始まっている。以下、概要を紹介する。

2.1 欧州の動向

2.1.1 セキュリティ標準化動向

欧州では、V2Xセキュリティに関しては、ETSI(European Telecommunication Standard

Institute)が担当して標準化を進めている。欧州指令M/453に対応して策定を進め、表2-1に

示す規格を策定している。これらは、先行して策定されたIEEE 1609.2 を基本的に踏襲す

る方針である。その上で、IEEE1609.2で不足する部分の分析を始め、多数の規格が策定さ

れている。

表2-1 ETSIで策定中・策定済みの協調システムセキュリティ関連規格

規格文書名 番号 状態 内容 Security;Stage 3 mapping for IEEE 1609.2

TS 102867

2012-6発行 ETSI標準類 IEEE1609.2の過不足

分析 セキュリティサービスと アーキテクチャ

TS 102 731

2010-09発行 セキュリティアーキテクチャ

脅威分析(TVRA) TS 102893

2010-03発行 脅威分析

SAP(サービスアクセスポイン

ト)

;ファシリティ層 TS 102 723-9

策定中 セキュリティサービスとファシ

リティ層の間を規定 ;対ネットワーク、 トランスポート層

TS 102 723-8

策定中 セキュリティ層とネットワー

ク・トランスポート層間を規定 ;対アクセス層 TS 102

723-7 策定中 セキュリティ層とアクセス層と

の間を規定 秘匿性サービス TS

102 943 2012-6発行 秘匿性に関するサービスを規定

トラストとプライバシマネジメ

ント TS 102 941

2012-6発行 プライバシ保護を考慮したPKIの仕組みを定義

アクセス制御 TS 102 942

2012-6発行 アクセス制御を規定

セキュリティアークテクチャと

マネジメント TS 102 940

2012-6発行 ITSセキュリティアーキテクチ

ャを規定 ITS G5のためのセキュリティヘ

ッダと証明書フォーマット TS 103 097

2013-4発行 セキュリティヘッダを規定

Page 11: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-11-

2.1.2 運用検討の状況

欧州におけるセキュリティシステムは、2012年11月に開催されたC2C-CCのワークショッ

プで紹介されたパイロットPKI(Public Key Infrastructure;公開鍵暗号基盤)の構築の説明

では、2013年第2四半期から運用を開始するとされていた。

この仕組みでは、車載システムに対して、長期CA(証明書当局)が長期証明書(機器ID

に相当するもの)を交付してもらう。これを仮名証明書当局に送信し、仮名のセットを受

け取る。この仮名は、比較的短い期間で切り替えて使う(図2-1中のPC1~PC4)。パイロッ

トPKIは、図2-2に示すようにFraunhofer研究所とEscrypt社が分担して構築・運用する。

2013年11月にETSI主催で、プラグテストと呼ばれる、相互接続性テストが実施されてい

る。ここでは、以下のセキュリティ規格に準拠してテストが行われている。

TS 102 931v1.1.1 Trust and Privacy Management

TS 103097V1.1.1 Security Header and Certificate Formats

(出典)Schoch、Securing Cooperative ITS,C2C-CC's Pilot PKI,2012)

図2-1 欧州のPKI概要

Page 12: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-12-

(出典)Schoch、Securing Cooperative ITS,C2C-CC's Pilot PKI,2012)

図2-2 欧州のFOT向けパイロットPKIの役割分担

Preserve(Preparing Secure Vehicle-to-X Communication Systems;欧州のV2Xセキュリティ

開発プロジェクト)のニュースによれば、このプラグテストまでに、1000台のITSステーシ

ョン(通信機)が登録された。約900の長期証明書と3000以上の仮名証明書がこれまでに発

行されている。

この一方で、課題も提起されている。ETSIワークショップ 2014年の報告の中で、署名

/検証の処理不足への対応と、正常な動作をしない機器への対処が課題であると指摘されて

いる。

前者は、ハードウェアによる高速処理での対応が検討され、Preserve プロジェクトで開

発が進められている。現状、毎秒1000程度の証明書検証が達成されている模様である。

後者は、2012年のETSI Security Workshopでも指摘されている。この際には、(完全な)

匿名性と、不正端末の検知・対処は、互いに相反する課題であり、両立は不可能と報告さ

れている。不正端末は、将来、問題を発生する可能性があるため、これを発見・管理する

仕組みの検討も始まっている(図2-3)。

Page 13: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-13-

(出典)Preserve プレゼン資料

図2-3 不正端末の検出

Page 14: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-14-

2.2 米国の動向

米国では、自動車メーカのグループCAMPと米国運輸省NHTSAとRITAが主導してセキュ

リティの開発・検討が進められている。標準化は、IEEEが1609シリーズとして検討を進め、

セキュリティに関しては、1609.2として発行されている。以下、公表資料を基に報告する。

2.2.1 検討されているシステム

CAMPとUS DOTで検討されている協調システムのセキュリティ管理システムの構成を

図2-4に示す。欧州のPKIに、不正端末の検知・取り消し(Misbehavior Detection and Revocation)

の機能を追加していることが特徴である。

(出典)Lukuc,Collaborative V2V Security Research Update, ITS-JPOワークショップ 2013)

図2-4 米国におけるPKI概念図

証明書を使ったメッセージの送信元、正しさの確認は、基本的に欧州と同様の仕組みを

使う。この機能の詳細を図2-5に示す。不正端末の監視当局(Misbehavior Authority)の中

に、検知機能(Global Detection)、証明書取り消しリスト生成(CRL Generator)を持って、

不正端末を検知し、その情報を関係当局に伝達すると共に、取り消しリストをネットワー

クに配信する。図2-6は取り消しに関わる当局の役割を示す。

これに加えて、初期登録時にEnrollment Certificate(登録証明)を交付する。この登録の

後、短期証明書(仮名証明書)を申請できる。

Page 15: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-15-

(出典)Lukuc,Collaborative V2V Security Research Update, ITS-JPOワークショップ 2013)

図2-5 米国のPKI全体像

(出典)Lukuc,Collaborative V2V Security Research Update, ITS-JPOワークショップ 2013)

図2-6 米国の協調システムPKIの不正端末検出のしくみ

Page 16: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-16-

短期証明書(仮名証明書)は、メッセージを継続して受信する方法での追跡を避けるた

め、短い期間(例えば5分間隔)で切り替える。こうすることで、送信元の認証と、追跡防

止という背反する状況を実現する。

2.2.2 研究開発・実用化状況

米国では、Safety Pilot Model Deploymentとして、2012年夏からミシガン州アナーバー市

で約3,000台の車両を使った協調システムの大規模実験が行われた。ここでは、証明書を使

ったメッセージ検証の仕組みを導入している。この中で、基本的なSCMS(Security Credential

Management System、又はSecurity Certificate Management System;セキュリティ確保のため

の重要な要素(鍵等)の管理システム、セキュリティ証明書管理システム)の検証と共に、

短期証明書(仮名証明書)群の更新に関する検証も実施されている(図2-7)。

(出典)Lukuc,Collaborative V2V Security Research Update, ITS-JPOワークショップ 2013)

図2-7 協調システムセキュリティに関するコスト分析の活動

2012年のNHTSAのワークショップでは、実装を意識して証明書を複数回使用する検討の例

が示されている。このワークショップ以前では、3年間分300,000程度必要とされていた証

明書(Pseudonym:仮名)が、3000-6000に削減でき、記憶容量も300KB程度になるとの報

告があった。コスト面では、機器コストの20%以内に収めるべきとの報告もされている。

2013年には、仮名証明書のダウンロードの方法として、3G携帯電話網とDSRCの比較検討

も行われている。現在は、SCMSの管理コストの算定と、SCMSシステム全体の攻撃に対す

る強さの評価、不正端末の検出と無効化の方法が課題となっている。

Page 17: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-17-

第 3 章 欧米協調

欧米の協調システムにおける研究開発に関する協力のMOUに基づき、規格のハーモナイ

ズのためのタスクグループ(Harmonization Task Group;以下HTGと略す)が開催された。

この内のHTG-1とHTG-6がセキュリティ関係を検討する。HTG-1は技術的な側面、HTG-6

はポリシー面の検討を担当する。

3.1 HTG-1

2012年11月に発行されたHTG1の報告書では、欧米の協調システムのセキュリティ関連の

課題が報告され、84項目の課題が抽出された。図3-1は、重要度別の件数である。その内、

表3-1に示す27項目が重要とされている(注:グラフと表の件数は差がある)。

(出典)Scott Cadzow, ITS-EU-US Harmonisation Review Security topics、2012)

図3-1 HTG1の検討結果:重要度別の抽出件数

Page 18: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-18-

表3-1 HTG-1で抽出された重要課題 項目記号 タイトル 該当 対応者

HTG1-VOB-01-D-01

Inclusion of generation time メッセージに生成時刻の有無 ETSI and SAE

HTG1-VOB-01-D-02

Choice of signature scheme 署名スキームの選択 (性能、知財権、拡張性を考慮)

ETSI and SAE

HTG1-VOB-01-D-03

Cross-layer issues in signing レイヤーの中で単一の署名が望まし

い ETSI and SAE

HTG1-VOB-01-D-04

Geonetworking TVRA ジオネットワーキングの脅威分析 ETSI

HTG1-VOB-01-D-06

Harmonization on modification of signed data format

将来の修正時の協調; ベース文書はIEEE1609.2

ETSI and IEEE

HTG1-VOB-02-I-01

Reversible pseudonymity 可逆偽名性 ETSI and SAE & stakeholders

HTG1-VOB-02-I-02

pseudonym change interval and algorithm

偽名変更の間隔とアルゴリズムに関

してガイドラインない Non-SDO

HTG1-VOB-03-D-1

Geographic region encoding 地理的範囲のエンコード;EUには

USに無いものがある ETSI

HTG1-VOB-03-D-2

Permissions encoding and PSID value:

パーミッションのエンコードと

PSID値 ETSI and SAE

HTG1-VOB-03-I-1

Service Specific Permissions サービス固有のパーミッションが未

規定 ETSI and SAE

HTG1-IOB-02-I-1

Revocation vs short lived certificates

証明書の失効か短期証明書か。不正

端末対策 Non-SDO

HTG1-SM-01-I-3

Permission encoding within signed message

PKI 構造;アプリケーション毎のCAの性質の規定

Non-SDO

HTG1-SM-01-I-4

PKI management PKI 管理:証明書の発行管理の仕組

みが未整備 Non-SDO

HTG1-SM-03-I-1

Specification of protocol for updating long term certificates

長期証明書の更新に関するプロトコ

ル仕様が未規定 IEEE

HTG1-SM-04-I-1

Specification of protocol for reversible pseudonymity

可逆偽名性に関するプロトコル仕様

が未定 IEEE, 、stakeholder

HTG1-SM-04-I-2

Specification of condition for reversible pseudonymity

可逆偽名性の条件の指定 Non-SDO

HTG1-SM-07-I-1

Specification of mis- behavior detection algorithm

不正動作検出アルゴリズムの指定 ETSI and SAE, following research.

HTG1-SM-07-I-2

Specification of global misbehavior reporting protocol

グローバル不正動作通知プロトコル

の指定 ETSI and SAE

HTG1-LTCS-02

Use of lower layer security mechanisms

下位レイヤのセキュリティメカニズ

ム;特にプライバシー関連で検討が

必要。EFCの例参考。

ISO / CEN / IEEE

HTG1-Adv-01-I-01

Security requirements for FSAP not specipied in ISO

サービス告知の脅威分析、 鮮度要件

SDO

HTG1-Adv-05-I-01

The ISO standards do not specify signing intervals (or any signing) for FSAP

FSAPの署名間隔が未規定。TVRAに

基づく検証ポリシー。 ISO / CEN / IEEE

HTG1-Adv-02 Signed Datagram Format 脅威分析に基づく署名付きデータグ

ラムのフォーマット ETSI / IEEE

HTG1-LL-03 Layer 3 networking (IP): privacy IP通信における最小限のセキュリテ

ィ要件 Non-SDO

HTG1-LL-04 Layer 2 security mechanisms: interoperability

レイヤ 2セキュリティメカニズム:

相互運用性 Non-SDO / stakeholder organizations

HTG1-PPS-01-1

Minimum requirements for platform security

プラットフォームの最低セキュリテ

ィ要件 ETSI / ISO

HTG1-PPS-01-2

Create minimum standards for platform security for platform running particular applications

最小限のプラットフォームセキュリ

ティ標準の作成 Non-SDO / ETSI / SAE

HTG1-PPS-02 Statement of platform capabilities to CA

CAへのプラットフォーム能力のス

テートメント ETSI / IEEE

(出典)Cadzow解説、HTG1報告書を基にJARIにて編集

Page 19: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-19-

3.2 HTG-6

HTG-6はセキュリティに関連したポリシー、管理の部分を扱う。2013年9月に作成された

HTG-6 Work Item Description(WID)に、検討内容が記述されている。

欧州では2015年に、米国でも近い将来、配備が予定される協調システムのために必要な

セキュリティ関連のポリシーの欧米の整合を図ることが目的である。

主な検討のポイントは以下の通り。

(1) 初期(Day One)アプリケーション実現のためのポリシーが協調して策定されること

(2) ポリシーは、関係者全てが許容できるセキュリティレベルを確保しつつ、ユーザ受

容性、効率性が受容できるレベルにあること。

(3) ポリシーが時間とともに拡張できること。

作業は、専門分野毎に分担検討を可能とするため、以下のように区分してで検討が進め

られる。

A.セキュリティ証明書の運用とセキュリティポリシー

B.端末と組織の認証ポリシー

C.不正行為対策

D.組織・運用の拡大・改良ポリシー

E.プライバシーポリシー

F.インフラストラクチャ

メンバーは米国・欧州とも、政府関係者、エキスパート(セキュリティポリシー、セキ

ュリティシステム管理、セキュリティ技術)、OEM/サプライヤー、プライバシーエキスパ

ート、インフラエキスパート、アフターマーケットデバイスサプライヤ、証明書エキスパ

ート等である。この会議には、日本、韓国、カナダ、オーストラリアからも代表を招聘す

る。作業は2014年1月の第1回から12ヶ月の間に、5~8回の1週間の会議を開催して進められ

る。

Page 20: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-20-

第4章 自動車セキュリティの検討状況

第3章までは、協調システムセキュリティの最近の動向について報告した。ここでは、自

動車セキュリティ全般に関する研究開発動向を報告する。

4.1 欧州プロジェクトの動向

欧州では、2000年代初頭から、車載ネットワーク、V2Xシステムのセキュリティに関す

る検討を、EC支援プロジェクトとして推進しており、現在も、Preserveプロジェクトが進

行中である。これらは、V2X通信のみならず、車載ネットワーク、車載インフォテイメン

ト(IVI;In Vehicle Infortainment)システムにまで及ぶ。欧州のITSセキュリティ関連プロジ

ェクトを表4-1に、年表を図4-1に示す。

表4-1 欧州の主な ITS関連セキュリティ開発プロジェクト

プロジェ

クト名 概要 主な対象 期間 全費用 /EC

支援 主な参加者

SeVeCom 主にV2X通信セキュ

リティ分析 V2X通信 2006

-2009 4.674M€/ 2.999M€

Trialog,ダイムラー,

Fiat,フィリップス,他 EVITA 車載ネットワーク、

セキュリティチップ

設計(ハードウェア)

車載ネット

ワーク 2008 -2011

6M€/ Fraunhofer SIT,BMW,

Continental,Escrypt, 富士通セミコン,他

Oversee セキュアオープン プラットフォーム

IVI 2010 -2012

3.9M€/ 2.8M€

Escrypt,Trialog,VOLKSWAGEN,他

Preserve 実用可能な V2Xセキュリティの

開発・実装

V2X通信 2011 -2014

5.438M€/3.85M€

Twente大,Escrypt,Trialog FraunhoferSIT, Renault

Euro-MILS

セキュアなプラット

フォーム IVI/ 車載ネ

ットワーク 2012 -2015

8.447M€/ 6M€

Sysgo,AirBus,他

図4-1 欧州の自動車セキュリティ関連プロジェクトの年表

Page 21: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-21-

こうしたプロジェクト以外に、SHEと呼ばれるハードウェアセキュリティ拡張、Autozar

と呼ばれる共通ソフトウェアプラットフォームの活動でも、セキュリティプロジェクトと

連携して活動している。以下、欧州のITSセキュリティ関係のプロジェクト概要を紹介する。

4.1.1 SeVeCom(Secure Vehicular Communication)

SeVeComは、欧州の FP6(6th Framework Program:第 6 次枠組みプログラム)の中で、

2006年 1 月 1 日から 2009年 3 月 31 日まで、TRIALOG、ダイムラー、フィアット、ボッ

シュ、EPA、Ulm 大学などが参加して実施されたプロジェクトである。車車間、路車間通

信ネットワークのセキュリティアーキテクチャを規定し、ネットワークの段階的なセキュ

リティ機能の配備を提案することを目的としている。

また、車両間通信のセキュリティとプライバシ問題の現実的な解を求めることも目指し

ていた。この中で、要求仕様、脅威分析、ベースラインアーキテクチャ、リファレンス実

装、学術面での検討などの成果を上げている。現在の協調システムにおけるセキュリティ

の基本的な部分(PKI、プライバシ保護)が検討されている。

図 4-2 に示すように、長期 ID と仮名(Pseudonym)の短期 ID を使い、送信メッセージ

の送信元の正当性と、メッセージの改変が無いことを証明する。仮名を適宜切り替えるこ

とで、メッセージ受信による追跡を防止する。

図 4-2 長期 ID と仮名の使用提案

このプロジェクトの成果で公表されている資料を以下に列挙する。SeVeComプロジ

ェクトの成果は、EVITA、Preciosa等のプロジェクトに引き継がれている。

D2.1 Security Architecture and Mechanisms for V2V/V2I (2008年)

D2.1 App.A Baseline Security Specification (2009年)

D1.1 VANETs Security Requirements(2006年)

D6.1 Project Presentation(2006年)

Page 22: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-22-

4.1.2 EVITA(E-safety Vehicle Intrusion proTected Application)

車載システムのセキュリティ確保を目的とし、ハードウェア(セキュリティチップ)の

試作までを行った。物理的なアクセス、無線インタフェース経由のアクセスの双方を想定

し、攻撃の防止、防御、封じ込めを目指した。全体を 4 期に分けて、検討が進められた。

各時期の実施内容を表 4-2 に示す。

表 4-2 EVITA プロジェクトの実施内容と時期

時期 項目 ゴール マイルストーン

M1 2009年 Q1

セキュリティ要求分析 ユースケース分析、脅威分析、 法的側面

脅威と要求

M2 2009年 Q4 M3 2010年 Q2

セキュア車載機器設

計 トラストモデル、ソフト/ハード分

担、HW セキュリティモジュール設

計、ソフトセキュリティ設計、 モデルベース検証

セキュリティと トラストモデル アーキテクチャ、 プロトコル仕様

M4 2010年 Q4

アーキテクチャ プロトタイプ

FPGA、ソフトベース 部分モデルベースコード生成、 コード検証

モデルベース検証 FPGAプロト、SWフレームワーク

M5 2011年 Q2

有効性検証とデモ 車載プロトタイプ、V2X 通信アプリ

ベースの安全アプリ フィールドでの有

効性検証、デモ

また、3 種類のセキュリティモジュールとして、Full、Medium、Light の設計が行われて

いる。

① EVITA Full

EVITA で設計した全ての機能を盛り込んだモジュールとして EVITA Full が提案されてい

る。主な機能は以下の通り

・CPU&RAM :セキュリティ機能専用の内部 CPUと内部 RAM(64Kb)を備え、

外部とのやり取りを読み出されるリスクを低減した

・NVM :不揮発性メモリー

・ECC-256 :非対称暗号エンジン、256ビット 楕円曲線アルゴリズム

・WHIRLPOOL :AES(Advanced Encryption Standard)ベースのハッシュ関数

・AES-128 :AES 対称暗号エンジン

・AES-PRNG :AES のための擬似乱数発生器

・COUNTER :セキュアなクロック代替

EVITA Full のモジュール構成を図 4-3 に示す。

Page 23: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-23-

(出典)EVITA 報告書より

図 4-3 EVITA-Full のモジュール構成

② EVITA Medium

Mediumは、Full から、ECC-256、WHIRLPOOLの 2 つの暗号エンジンを除いた構成

になっている。このため、暗号化に高速処理を必要としない用途を想定している。

EVITA Mediumのモジュール構成を図 4-4 に示す。

(出典)EVITA 報告書より

図 4-4 EVITA-Medium のモジュール構成

③ EVITA Light

Light は、Mediumから、更に CPUとカウンターを除いたもので、内部 RAM、内部

NVM もオプション扱いとし、主に、セキュリティを確保すべきセンサー、アクチュエ

ータに対して安価なソリューションを提供する。これにより、少なくとも、センサー、

アクチュエータの認証、データの正当性、秘匿性の確保が可能となる。これら 3 種類

と、SHE(Secure Hardware Extention;ドイツの OEM グループの仕様に基づく CPUの

セキュリティ拡張機能)、TPM(Trusted Platform Module)の機能比較を表 4-3 に示す。

Page 24: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-24-

表 4-3 主なハードウェアセキュリティ機能の比較

HSM EVITA Full EVITA Medium

EVITA light

SHE TPM スマート

カード 起動時完全

性保護 認証とセキュ

ア 認証と セキュア

認証と セキュア(Opt)

セキュア 認証 なし

HW 暗号アル

ゴリズム(鍵

生成含む)

楕円曲線暗号、

ECDH,AES, MAC, HMAC WHIRLPOOL,

楕円曲線暗号、

ECDH,AES, MAC, HMAC WHIRLPOOL,

AES, MAC

AES, MAC

RSA, SHA-1, HMAC

ECC,RSA, AES,3DES, MAC, SHA-x

HW 暗号加速 ECC,AES, WHIRLPOOL

AES AES AES なし なし

内部 CPU 有り(プログラ

ム可) 有り(プログラ

ム可) なし なし /プリセ

ット プリセット 有り(プログ

ラム可) 乱数発生 擬似乱数+

乱数種 擬似乱数+ 乱数種

擬似乱数+ 外部乱数種

擬似乱数+

乱数種 真性乱数生

成 真性乱数生

成 カウンター 16x64ビット 16x64ビット なし なし 4x32 bit あり

内部不揮発

性メモリー 有り 有り オプション 有り 間接(SRK経

由) 有り

並行アクセス 複数セッション 複数セッション 複数セッション なし 複数セッション なし

タンパ保護 間接(パッシブ、

ASIC の一部) 間接(パッシブ、

ASIC の一部) 間接(パッシブ、

ASIC の一部) 間接(パッシブ、

ASIC の一部) 有り(メーカ

依存) 有り(アクティ

ブ、EAL5 まで)

主な想定用

途 V2X システム 車載 ECU

センサ、アクチ

ュエータ 車載 ECU PC等

表 4-4 に、EVITA のホームページに公開(ID 登録は必要)されている報告書のリス

トを示す。

表 4-4 EVITA 報告書リスト

No. Deliverable name Date D0 Project summary Apr. 2012 D1.2.5.1 Presentation slides from the EVITA Workshop on 1 July 2010 Jul. 2010 D1.2.5.2 Presentation slides from the Final EVITA Workshop(Nov23) Nov. 2011 D1.2.6 Final liaisons documentation Mar. 2012 D1.2.7 Final dissemination strategy Apr. 2012 D2.1 Specification and evaluation of e-security relevant use cases Dec. 2009 D2.3 Security requirements for automotive on-board networks based on

dark-sidescenarios Dec. 2009

D2.4 Legal framework and requirements of automotive on-board networks

Sept. 2011

D3.1 Security and trust model Nov. 2009 D3.2 Secure on-board architecture specification Aug. 2011 D3.3 Secure on-board protocols specification Jul. 2011 D3.4.3 On-board architecture and protocols verification Dec. 2010 D3.4.4 On-board architecture and protocols attack analysis Dec. 2010 D4.0.3 Security architecture implementation – Progress report Jul. 2011 D4.2.3 LLD modelling, verification, and automatic C-code generation Jan. 2012 D4.4.2 Test results Feb. 2012

Page 25: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-25-

4.1.3 SHE(Secure Hardware Extention)

SHEは HIS(Hersteller Initiative Software)により策定された仕様に基づく、ECU のセキ

ュリティ拡張機能である。HSI はドイツの OEM から構成されるグループで、Audi、BMW、

Daimler、Porsche、Volkswagenが加盟している。最新のセキュリティ仕様は 2010年 6 月発

行となっている。前節で説明したように、EVITA light に近い機能を持つと言われている。

車載用の CPUに付加して利用することを想定されており、この仕様に基づく ECU が、富

士通、NXP、Infenion等から販売されている。

4.1.4 Preserve(Preparing Secure Vehicle-to-X Communication Systems)

Preserveプロジェクトは、欧州委員会の FP7の中の一つで、2011年 1 月から 2014年

12月末まで、総額 5.4百万ユーロの予算で進められている。Twente大学を中心に、Escrypt、

FraunhoferSIT、FraunhoferAISEC、Trialog、Renault、KTH で推進されている。それ以前

のプロジェクトで開発された要素との関係を図 4-5に示す。

(出典)Petit,Preserve Overview,2012.11.15

図 4-5 Preserve で開発するモジュールと、それ以前のプロジェクト成果の関係

Page 26: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-26-

図 4-6 Preserve プロジェクトの FPGA(左)、評価システム構成(右)

EVITA Full をベースに、実用可能な V2X システムを開発するとしている。

表 4-5 に公開されている報告書のリストを示す。

表 4-5 Preserve 報告書リスト

No. Name WP no. Nature Diss. Deliverydate D1.1 Security Requirements of VSA WP1 R PU 6 D5.1 Deployment Issues Report V1 WP5 R PU 17

D6.1 Y1 Dissemination Report WP6 R PU 12 D3.1 FOT Trial 1 Results WP3 R PU 33 D5.2 Deployment Issues Report V2 WP5 R PU 24

D6.2Y2 Dissemination Report WP6 R PU 24

4.1.5 Oversee(Open Vehicular Secure Platform)

Oversee(2010年~2012年)は、インフォテイメント等の車載システムのオープン化とセ

キュリティの検討のプロジェクトである。このプロジェクトは、セキュリティを考慮した

アーキテクチャが特徴で、共通のプラットフォーム上に複数の、互いに隔離された実行環

境を構築し、外部との入出力を管理することで、セキュリティを確保するとしている。図

4-7 に公開されている階層構造の概念図を、表 4-6 に公表されている報告書リストを示す。

Page 27: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-27-

(出典)Overseeホームページ

図4-7 Overseeの概念図

表4-6 Overseeの公表資料

Del. no Deliverable Name Delivery Date published

D1.1 Use Identification (Final Draft) [pdf] April 2010 ○ D1.4 Functional requirement analysis (Final Draft) [pdf] August 2010 ○ D1.5 Non-Functional requirement analysis (Final Draft) [pdf] August 2010 ○ D2.1 List of interfaces and specification of information flow in and

through OVERSEE.(Final Draft) October 2010 ○

D2.2 Specification of security services incl. virtualization and firewall mechanism.(Final Draft)

December 2010 ○

D2.3 Description of building blocks; interfaces and localization of building blocks. (Final Draft)

December 2010 ○

D2.4 Specification of secure communication. (Final Draft) December 2010 ○ D2.5 Definition of the requirements for validation of OVERSEE

implementations.(Final Draft) December 2010 ○

D3.1 Selection for reuse of existing building blocks. (Final Draft) December 2010 ○

4.1.6 EURO-MILS(Multiple Applications Platform for Certified Separation)

2012年から 2015年までの予定で始まった EC 支援プロジェクトで、(航空機にも実績の

ある)複数の OS 環境を安全に共存させることを目指したプロジェクトである。基本的技

術は、SYSGO社が開発した PikeOS上に複数の OSを搭載することである。2013年 11 月に

開催された Escarにおける報告では、プロジェクトの背景として、自動車の差別化は、ソ

Page 28: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

フトウェアが担う部分が大きくなっており

膨れ上がっていることが紹介されていた

値を引き上げており、これに対応するために

フトは再利用が必要で、オープンソースも利用しなければならない

メーカはソフトウェアを管理しなければならない

リの種類に応じた適切な分離と管理

である。こうしたことに対応するために

Overseeと同様に、複数のアプリケーションを互いに隔離

を確保する考え方である。EURO

際標準 CC(ISO 15408)の EAL

(図 4-8)安全対応ドメインと

ている。(安全に対して厳しい規格を持つ航空業界で実績)ドメイン分離の主な手段はアク

セス制御と情報フロー制御を時間的・空間的に実施することで実現している(図

こうして、EURO-MILS は安全とセキュリティが組み込まれたプラットフォームであると

している。

図 4-8 EURO

-28-

フトウェアが担う部分が大きくなっており、このために、高級車は 1 億行のコード規模に

膨れ上がっていることが紹介されていた。同時に、コンシューマ技術の進歩が顧客

これに対応するために、自動車はクラウドと繋がる必要がある

オープンソースも利用しなければならない。この一

メーカはソフトウェアを管理しなければならない。こうしたニーズの対応のために

リの種類に応じた適切な分離と管理、信頼性の保証のための構成証明の手法の提供が必要

こうしたことに対応するために、Euro-MILS プロジェクトが始められた

複数のアプリケーションを互いに隔離、相互の通信のセキュリティ

EURO-MILS のプラットフォームの特徴は、

EAL(評価保証レベル)5-7 に対応するとしていることである

)安全対応ドメインと、外部に繋がるドメインは、ベースとなる

(安全に対して厳しい規格を持つ航空業界で実績)ドメイン分離の主な手段はアク

セス制御と情報フロー制御を時間的・空間的に実施することで実現している(図

は安全とセキュリティが組み込まれたプラットフォームであると

(出典)Tverdyshev

EURO-MILS プラットフォームのセキュリティ評価

億行のコード規模に

コンシューマ技術の進歩が顧客の期待

自動車はクラウドと繋がる必要がある。ソ

この一方で、自動車

こうしたニーズの対応のために、アプ

信頼性の保証のための構成証明の手法の提供が必要

プロジェクトが始められた。

相互の通信のセキュリティ

、セキュリティの国

に対応するとしていることである

ベースとなる PikeOSで分離し

(安全に対して厳しい規格を持つ航空業界で実績)ドメイン分離の主な手段はアク

セス制御と情報フロー制御を時間的・空間的に実施することで実現している(図 4-9~4-10)。

は安全とセキュリティが組み込まれたプラットフォームであると

Tverdyshev、Escar2013

プラットフォームのセキュリティ評価

Page 29: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

図 4-9 対象とする

図 4-10

コンシューマ技術との連携の

載する例を示す。

-29-

(出典)Tverdyshev

対象とする ECU(左)とアーキテクチャ(右)

(出典)Tverdyshev

セキュリティドメイン分離(論理分離)

コンシューマ技術との連携の一例として、図 4-11にアンドロイド OS

Tverdyshev、Escar2013

(左)とアーキテクチャ(右)

Tverdyshev、Escar2013

OSを Head Unitに搭

Page 30: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-30-

(出典)Tverdyshev、Escar2013

図 4-11 アンドロイド OS への対応例

4.1.7 Autozar(AUTomotive Open System ARchitecture)

欧州の車載電子システムのプラットフォーム構築の活動 Autozarにおけるセキュリティ、

特に、安全上重要な区分の検討内容が 2013年の Escarで紹介された。

車載組込みシステムの現状の制約として、

・演算、記憶リソースの制限(<200MHz,4MB RAM)

・リアルタイム性の厳しい要件

・安全要件(ISO 26262)

・通信は主に CAN(<1Mbit/s)

・コード自動生成が広く使われる

・マルチコアは使われ始めた段階

・メモリー保護も始まったばかりであること

等が紹介された。

こうした状況に対して、Autozarで提供できるセキュリティ機能の紹介があった。これら

は、

・個々のタスクに対して特権レベル付与

・セキュリティライブラリー(CAL,CSM)

・ECU 間の通信におけるセキュリティ機構

である。

Page 31: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-31-

現在は、周辺と個別機能に関してセキュアにしていくアプローチを取っている。Autozar

における全体的な視点とアーキテクチャ、及び安全機構との協調が必要になるとしている。

外部との接続に関する最近のトレンドは、セキュリティの必要性の認識を広める効果があ

るとしている。図 4-12は、Autozarの基本構成、図 4-13は、ハイパーバイザ上でパーティ

ションでドメインを区切る概念図である。

(出典)Stumpf、Escar 2013プレゼンより

図 4-12 Autozar の基本ソフトウェア構成

(出典)Stumpf、Escar 2013プレゼンより

図 4-13 ETAS が提案するセキュア OS アーキテクチャ

Page 32: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-32-

4.1.8 まとめ

欧州では、EC委員会のFrameWorkProgramの一環として、様々なセキュリティ機能開発が

進められており、現在も、2件が進行中である。こうしたプロジェクトの成果の一部は公開

されており、こうした報告からその概要を知ることは可能である。今後、詳細の分析が望

まれる。

4.2 米国の状況

米国では、自動車メーカによるコンソシアムCAMPやDOT NHTSAにおいて、V2X通信に

おける通信セキュリティの検討が進められてきた。また、IEEEでは、1609シリーズの標準

化の一環でセキュリティ標準1609.2が策定されている。

一方で、自動車そのものに対するセキュリティ観点での検討も近年活発になっている。

主な検討グループは、SAE、TRB並びに前出のNHTSAである。

SAEでは、2011年から委員会活動を進めており、ハードウェアセキュリティモジュール

(SHE、EVITA、TPM)の分析などを進めてきた。現在、セキュリティガイドラインの取

りまとめを行っており、2014年6月頃までに発行予定である。以下のような目次が想定され

ている。

・序論

・自動車向サイバーフィジカルシステムのガイド原理

・プロセス

・全体的なセキュリティ管理

・概念フェーズ

・ハードウェアレベル

・ソフトウェアレベル

・基盤プロセス

・参照文献

NHTSAは自動車の安全関連電子制御システムに関する研究を進めている。これは4つの

柱から成っている。1つは情報収集、2つ目は自主的ガイドラインの支援、3つ目は技術的・

運用面の要件検討、4つ目はサイバーセキュリティに関するポリシー・規制の検討である。

2014年度は約2億円の予算を要求し、クラウド連携に伴う自動車のセキュリティ、セキュリ

ティインシデントの共有のしくみ(ISAC)組織の検討等を実施するとしている。

Page 33: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-33-

4.3 その他の動き;TCG(Trusted Computing Group)

これまでは、主に、車載システムを守る考え方の対策を紹介した。これとは異なるアプ

ローチとして、システム(ECU、その他)のパラメータを安全に保管し、これに対して改

変が施された場合に、これを検知する仕組みの検討も行われている。オフィスなどで用い

られる一般のコンピュータには、TPM(Trusted Platform Module)と呼ばれるチップが普及

している。TPMはセキュアなハードウェアとセキュアなメモリ等から構成される。図4-14

にTPMのソフトウェアの構成を示す。

このTPMは、システムを起動する際に、システムのCPU等に先立って起動し、CPUのBios

から、各種設定、外部機器の設定を確認し、これをセキュアにモジュール内の安全な場所

に格納する。システムから読み出した値と、格納されていた値とが差異が生じた場合、こ

れを記録する。サーバ等に送信する仕組みを作れば、異常時に情報を送信できる。将来、

ソフトウェアのリモートアップデートを実現する場合、対象となるシステムに搭載されて

いるECU/CPUの型番、ソフトウェアバージョン、マルウェアに感染しないか、等を調べる

ことが必要である。こうした場合に、外部からソフトウェアを送信する前に、システム設

定を確認することで、正しいソフトウェアを導入することができる、としている。

(出典)TCGホームページより

図4-14 TPMの構成例

Page 34: 協調システム並びに周辺のセキュリティjari.or.jp/Portals/0/resource/pdf/H25jigyo/S13-1_app2.pdf · -8- ュアなメモリ、 cpu 、タンパ証跡)であるとしている。表1-3にコモンクライテリア

-34-

第5章 まとめ

協調システムの配備を間近に控え、セキュリティ確保のためのPKIの仕組みの実用性(機

能、性能、コスト)の検討、検証が盛んに行われている。これに加えて、米国では、不正

な情報を送信する端末を排除する仕組みを当初から盛り込む意向で検討が進められている。

欧州は、こうした仕組みと、プライバシー保護の両立が難しいことから、当初は省略する

ことを想定しているが、仕組みの検討を始める動きも見られる。

この他、欧州のC2CC-CCでは、通信する相手が信頼できるかどうか、という観点でTrust

Assurance Levelという評価手法を提案している。これは、単にV2Xのセキュリティ対策に

留まらず、自動車システムのセンサに至る構成要素のセキュリティ対策を問う仕組みにな

っており、注意が必要と見られる。

欧米は、協調システムセキュリティに関しても、整合化を図る活動を進めており、既に

技術面は検討が終わっている。現在、ポリシー面の検討が始まっており、2014年中に結論

を得ることを目標にしている。

従来、欧州が積極的に自動車セキュリティの研究をECの支援を受けて進めて来た。これ

に対して、米国もサイバーセキュリティ検討の取り組みを強化している。

今後、自動車が外部と繋がる機会が増えてくると予想されるため、セキュリティ関連の

インシデントの増加が予想される。これに備えて、適正なセキュリティ対策を検討・配備

していくことが重要であると考えられる。