01

セキュリティー関連の機能は数年前から車両に搭載されており、 今日では暗号化や署名検証などの暗号処理がイモビライザーやECUのセキュアなリプログラミングなどに使用されています。 常時接続が前提となると、OTA (Over The Air) を用いたソフト ウェア更新、リモートからの機能の有効化、路車間通信 (V2X) などによって車両の機能が拡張されます。それらのユースケースからは自動車業界の将来を約束するビジネスモデルが生まれ、人々の 関心を引き付けています。しかし、常時接続により、車両に対するサイバー攻撃の危険性も増加します。

鍵：サイバーセキュリティーの基盤

自動車業界はサイバー攻撃のリスクに対抗するために、業界独自のセキュリティー対策を導入するだけでなく、IT業界のセキュリ ティー分野の従来手法も導入しています。たとえば、AUTOSAR で標準化されているSecure Onboard Communication (Sec-OC)[1]が、車両ネットワーク内のECU間の通信を保護する一方、 IT分野ではお馴染みのTLS (Transport Layer Security) や IPSec (Internet Protocol Security) などのプロトコルも、通信バスとアプリケーションによっては利用されるかもしれません。

しかし、現代のどのセキュリティーメカニズムにも共通する特徴の1つに、採用する暗号化アルゴリズムの機密性ではなく、使用する鍵の機密性によって実現されるということです。また、セキュリ ティーをさらに高めるため、鍵はいずれも1つのセキュリティー メカニズムにしか使用しません。サイバーセキュリティーアプリケーションの増加に伴い、共通鍵、公開鍵ペア、電子証明書といった多数の暗号マテリアルを安全に格納する必要が多くのECUで生じています。こういった仕組みは 「鍵保管」や「車両鍵管理」と呼ばれます。両者の違いを以下で 説明しましょう。

暗号鍵のセキュアな保管

ここ数年、ハードウェアを用いたセキュリティー機能に関する標準化が進んでいます。これにより、マイクロコントローラーに搭載された特殊なハードウェアユニット、すなわち Hardware Security Module (HSM) で、鍵の安全な保管と暗号動作の高速化が可能となります。AUTOSARコンソーシアムは鍵のモデル化と暗号化サービスの 利用を実現するため、暗号機能のベーシックソフトウェアを標準化

サイバーセキュリティーに必須の鍵のセキュリティー標準化された鍵管理でECUを守る新たな機能やビジネスモデルをサポートするために車外のITシステムに接続する機能をもつ自動車はますます増えています。そのような「つながるクルマ」をサイバー攻撃から守るために、鍵や乱数を用いたセキュリティー機能が利用されます。では、鍵管理が対処すべき 課題にはどのようなものがあるのでしょうか。そして、AUTOSARにおけるセキュリティー機能の標準化にはどのようなメリットがあるのでしょうか。

02

Technical Article / September 2019

内に存在する鍵から導出したりすることもしばしば必要になります。秘密鍵をECU間で共有する場合は、それらの鍵の機密性と完全性が常に確保されていなければならず、たとえば秘密鍵をバス上に平文で送信することはできません。

4. アフターセールスおよび廃棄：キーマテリアルの更新および 追加インストール。たとえば、遠隔からの機能の有効化にも適切な鍵が新たに必要になります。故障したECUを入れ替える場合も、重要なキーマテリアルが故障ECUから読み出されたり、何らかの形で操作されたりすることがないような対策を講じなければなりません。そして、新しいECUに適切なキーマテリアルを与え、そのECUが機能を実行できるようにしなければなりません。

鍵管理の運用

Secure Onboard Communicationは、さまざまな鍵管理手法を応用している例の1つで、ECU間の車内通信の妥当性確認に 使われています。SecOCによりリプレイ攻撃の検出、送信側の 正当性チェック、伝送データの完全性の検証などをメッセージの 受信側が行えるようになっており、受信側ではそのためにいわゆるメッセージ認証コード（MAC）のチェックが実施されます。MACは基本的には暗号化されたチェックサムで、送信側が生成し、受信側が妥当性を検証します。MACの検証に失敗すると、受信側はそのメッセージを廃棄します。パフォーマンス上の理由から、MACの 計算には対称暗号アルゴリズムが使用されます。この手法では、メッセージの送信側も受信側も、すべてのECUが同じ秘密鍵を使用してMACの生成・検証を行います。この鍵は そのライフサイクル全体で機密性が保たれていなければならず、したがってそれを保護しないまま車内ネットワークや車外ネット ワークで伝送することは許されません。以下の運用の例では、量産時の鍵の生成とインストールに焦点を合わせています。それぞれの運用の評価はここでは行いませんが、これらを見ると、実際には鍵管理には多様なソリューションが 存在すること、しかも、同一のユースケースであるにも関わらず 異なるソリューションが存在することがわかります。この例ではSecOC用のキーマテリアルを生成し、それを配布しています。

しました[2]（図1）。これによって、ソフトウェアやHSMが提供 するセキュリティー機能を利用するための、標準化されたインターフェイスが提供されます（図2）。ハードウェアとソフトウェアをこのように組み合わせることで、キーマテリアルを効率的かつ安全にECU内に格納できるようになります。

暗号鍵のライフサイクル

自動車の場合、鍵の利用は日常的な動作モードのみに限定されません。鍵管理は車両ライフサイクルにおける以下のフェーズでも考慮しなければなりません（図3）。1. ECU開発：ECUへの初期鍵の格納2. 車両への統合：初期鍵と開発鍵の入替え3. 車両の量産：初期または開発鍵と量産鍵の入替え。さらに、 他のキーマテリアルを外部ソースからインストールしたり、車両

図1：鍵のモデル化と暗号サービスの利用を目的とする AUTOSAR Crypto Stack

図2：Hardware Security Module (HSM) の アーキテクチャー

03

Technical Article / September 2019

に対応していました。同じタイプの問題の解決にそれぞれ異なるアプローチを取り、そしてそれらを維持していくのは、どの関係者にとっても余分な負担です。また、鍵管理は通常は製品の差別化や強みにつながる特性とは言えません。そのためここに最適化の余地があることが認識され、それに呼応して鍵管理の機能が AUTOSAR 4.4 Securityにより新しく標準化されました。この 結果、鍵管理の専用モジュールであるKeyM[3]の仕様が策定されています（図4）。このモジュールはCrypto KeyとCertificateの 2つのサブモジュールで構成されています。Crypto Keyサブモジュールは鍵のネゴシエーションのための機能 を提供します。このプロセスは2つのフェーズに分かれており、 最後のフェーズではCrypto Stackを利用したキーマテリアルの導出や鍵のHSM内への格納が行われます。自動車メーカーが 定義するロジックは、先に述べたような問題点からKeyMモジュールでは実装されず、 鍵ハンドラーと呼ばれるソフトウェアコンポーネントで実装されます（図4）。Certificateサブモジュールは、証明書の解析、検証、インストールの機能を提供します。これによってアプリケーションは証明書の 所定のエレメントを取得し、さらなる処理を行うことができます。 最後のフェーズでは、証明書はECUの不揮発性メモリー（NVM）もしくはHSMに格納されます。ベクターはAUTOSAR Security Extensionsコンセプトグループの主導的な立場にあり、鍵管理の標準化に当初から関与して きました。このグループによって設定された要求は、そのまま AUTOSARベーシックソフトウェアであるMICROSARの開発へとつながっています。

標準化の課題

鍵管理は自動車メーカーやサプライヤーでの開発、量産、アフターセールスのプロセスに強く結び付いています。そして、キーマテリアルは数年前から複数の機能に使用されているため、公開鍵基盤（PKI）などの一部のITインフラがすでに存在しています。自動車メーカーはこういった既存のインフラを再利用する傾向が高い ため、標準化はなかなか進みません。暗号鍵の生成にオンボードとオフボードのどちらの手法を選ぶかも既存のインフラや今後の インフラに左右されますし、その自動車メーカーが定めるセキュリ ティー目標も鍵管理に影響します。これらの目標は、開発、量産、 サービス環境でのセキュリティーにどのような前提を置くかといった、多様な因子に基づいて設定されます。たとえば車両の量産

オフボードでの鍵の生成

運用の1つは、オフボードの鍵管理サーバーを使用してSecOCに必要な鍵を生成する手法です。このサーバーは車両に搭載されているECUの情報と、SecOC鍵に対する各ECUのニーズを把握 していなければなりません。ECUは必要な鍵を車両製造時に取得します。鍵の機密性が必要であるため、伝送中は暗号を用いて 鍵を保護しなければなりません。受信側のECUは信頼性と完全性をチェックしてから鍵を格納します。

コーディネーターを使用したオンボードでの鍵の生成

この運用では、テスターはSecOC鍵を生成するための認証子付きのリクエストを作成し、コーディネートを行うECUに送信します。コーディネーター役のECUはまず、車両固有の共通の鍵を生成 します。そして、鍵共有プロトコルを使用して、鍵の配送先となる各ECUとの間に一時的に安全な接続を設け、先に生成した鍵を 伝送します。ターゲットECUはこの鍵と鍵導出の仕様に基づき、 適切なSecOC鍵を各自で生成します。なお、この鍵共有プロト コルは実行時間が長いため、鍵の生成と配布にしか使用されま せん。すべてのECUが生成した鍵を用いてSecOSで、相互に安全かつ効率的に通信を行います。そのための新たな鍵の配布は不要です。

コーディネーターを使用しないオンボードでの鍵の生成

次に、SecOCのキーマテリアルをオンボードで生成する方法ですが、鍵を生成するための要求がコーディネーター役のECUに送信されるのではなく、ECUのグループ全体に直接送信されます。 各ECUはグループに所属するECUを把握しており、多段階の鍵交換手続きを開始します。メンバーのECUはメッセージを交換して共有鍵を生成しますが、このとき、バス経由で共有鍵そのものを 送信することはありません。グループ内の全ECUが共有鍵を算出すると、メンバーのECUは鍵導出の仕様に基づき、必要なSecOC鍵をそれぞれで生成します。

標準化の状況

鍵管理はこれまで標準化されてこなかったものの、ソリューションはやはり必要であり、自動車メーカーは各自のアプローチでこれ

図3：車両ライフサイクルの全体におよぶ鍵管理

04

Technical Article / September 2019

工場等をセキュアと見なすかどうかに共通見解はなく、それらの 前提は量産やアフターセールスに鍵を導入する際の事前対策に そのまま反映されます。量産でのパフォーマンスの要求も鍵管理に影響します。車両の 全ECUに鍵を伝送するのに使える時間が2、3秒しかなければ、 それに沿った鍵管理の運用を決めなければなりません。

標準化でバリエーションを減らす

暗号化アルゴリズムとそれに関連するキーマテリアルは、現代の自動車のセキュリティーを支える土台です。それらを使用して、 革新的な機能や基盤となるビジネスモデルが攻撃から守られるのです。 AUTOSAR 4.4で導入されたKeyMモジュールは、標準化に向けた最初の一歩です。それは特定の鍵管理の運用を標準化するのではなく、多様な運用を実装するための汎用的なインターフェイスを提供します。自動車コミュニティーは、鍵管理の運用を協調させる取組みにもっと本腰を入れなければなりません。そうすることで主要な運用に対する鍵ハンドラーの標準化が可能になり、結果と して実際に使用される運用の種類を減らすことができます。高いレベルの標準化には、コストとソリューションの数を削減できる 可能性が存在するのです。

本稿は2019年9月にドイツで発行されたAutomobil Elektronikに掲載されたベクター執筆による記事を和訳したものです。

Falco K. Bapp博士ベクターのHSM用ソフトウェアスタックである「vHsm」の プロダクトマネージャーとして、アーキテクチャーと機能範囲 を定義。

画像提供元：Vector Informatik

参考文献：[1] AUTOSAR 4.3 WP-X-SEC (2016), Requirements on Module Secure Onboard Communication[2] AUTOSAR 4.3 WP-X-SEC (2016), Requirements on Crypto Stack[3] AUTOSAR 4.4 WP-X-SEC (2018), Specification of Key Manager

■ 本件に関するお問い合わせ先ベクター・ジャパン株式会社 営業部E-Mail: sales@jp.vector.com

Antonio Almeida博士セキュリティーガバナンス分野のプロダクトマネージャー。 自動車のセキュリティー標準規格に対する開発プロセスの コンフォーマンスを担当。

図4： AUTOSARで標準化されたKeyMはCrypto KeyとCertificateの 2つのサブモジュールを持つ

Eduard Metzker博士ベクターサイバーセキュリティーソリューションのプロダクト マネージャーであり、MICROSARベーシックソフトウェアの セキュリティーメカニズムを定義。 また、AUTOSARの数々のセキュリティーメカニズムを規定 するAUTOSAR 4.4 Security Extensionsコンセプトグルー プの責任者。