車載用MACsecの基盤となるキープロビジョニング

コネクテッドカーのセキュリティ対策は、もはや避けて通れない最重要課題です。特に、UNECE R155などの法規制は、より堅牢な車載ネットワークの構築を求めています。

その切り札として注目されるのが、ハードウェアレベルで通信を保護する「MACsec」 。しかし、その導入は一筋縄ではいきません。「なぜか期待した性能が出ない」「実装が複雑で開発が遅延する」――そんな壁に直面していないでしょうか？

実は、その原因はMACsec自体ではなく、その土台となる『キープロビジョニング（鍵供給）』の方法にあるかもしれません。本ページは、MACsecの性能を左右する鍵供給の選択肢を徹底比較 。多くの開発者が選択しがちな手法に潜むパフォーマンスの罠を解き明かし、コストと性能を両立する最適解を提示します。

u.trust Converged HSM CSAR – 多用途向け統合HSMプラットフォームの概要紹介はこちら
お問い合わせはこちら

1. はじめに

ここ数年の重要なトレンドとして、自動車メーカー（本ページではOEM（Original Equipment Manufacturer）と呼びます）は、UNECE規則155（サイバーセキュリティおよびサイバーセキュリティ管理システム）などのセキュリティ規制に対応するため、自社車両のセキュリティを積極的に調査しています。
この規制を遵守するということは、OEMがセキュリティコンセプトを構築し、ユースケースを詳細に確認し、車両に統合するための最新のセキュリティソリューションを探さなければならないことを意味します。OEMはまた、工場で製造される車両やサービスで修理される車両を含め、製品のライフサイクル全体をカバーする必要があります。
ITセキュリティとは対照的に、自動車のセキュリティは、販売される製品のより長いライフサイクルをカバーしなければなりません。信頼できない第三者による修理を可能にし、実施する必要があり、時には、最終製品のユーザーが規制で義務付けられているセキュリティ対策（走行距離の改ざんなど）を回避しようとすることがあります。
車両には100台以上の電子制御ユニット（ECU）が搭載され、アプリベースの機能、高音質オーディオのストリーミング再生、インターネット接続、自動運転機能、先進運転支援といった機能を実現するために相互に通信を行います。ユースケースに応じてセキュリティ要件は異なりますが、安全性に関するユースケースは最も重要です。

車両OEMは、すべての重要な課題をカバーするために、幅広いセキュリティソリューションを検討する必要があることは明らかです。ソフトウェア署名やセキュアブートのような多くは、セキュアな基盤を構築するために必要ですが、究極の基盤は信頼の礎、すなわち証明書と鍵のセキュアな管理です。
本ページでは、特にバックエンドと車載コンポーネント間の分散機能として、証明書と鍵をセキュアに管理するためのソリューションについて説明します。これには、OEMが利用できるさまざまなオプションが含まれます。
車載用MACsec（Media Access Control security）を例に、オフボードとオンボードの設計判断が、ソリューション全体がどのようにまとまるかにどう影響するかを示します。MACsecは、現時点で車両用の唯一の真に統合された通信システムである車載イーサネットにとって、画期的なネットワークセキュリティソリューションです。

2. 証明書と鍵のセキュアな管理

最新の自動車セキュリティシステムのほとんどは、信頼とセキュリティを確保するための基本的なツールとして暗号技術を使用しています。
セキュリティシステムで使用される主な暗号機能は次のとおりです。

• データの機密性を実現するための暗号化
• データの認証と完全性保護を実現するための認証

これらの暗号操作では、鍵を使用してこれらの機能をパラメータ化し、鍵のみを機密に保つ必要がある一方で、これらの機能の標準化を可能にしています。さまざまな種類の鍵が存在しますが、主な分類は「対称鍵」と「非対称鍵」です。対称とは、関数の両方の操作（例えば、暗号化と復号）が同じ鍵を使用することを意味し、非対称は異なる鍵（例えば、暗号化用と復号用に別の鍵）を使用します。使用されるこれら2種類の鍵に基づいて、暗号機能も対称アルゴリズムと非対称アルゴリズムに分類できます。
非対称キーについて考えると、多くの場合、これらは暗号化証明書の一部として使用され、たとえば、インターネット上の HTTPS のセキュリティを有効にします (TLS 証明書)。

暗号アルゴリズム、鍵、および証明書の個々の選択は、ほとんどがOEMの管理下にあります。行われる選択は、ユースケースだけでなく、生産される車両の技術的要件にも大きく依存します。安全性が重要な製品の技術規制の必要性は自明です。高度に自動化された生産およびスペアパーツプロセスに対する要件も基本です。重量、サイズ、コストもユースケースに応じた重要な考慮事項です。これらの要件は、使用されるチップ上の利用可能なリソースを含め、車両とその内部のハードウェアの設計に大きく影響します。その結果、暗号アルゴリズム、鍵、および証明書の選択が影響を受けます。

車両生産は、Tier-1と呼ばれる、独自の製造を行い、さまざまなOEMのために働くメーカーによって製造された、さまざまなECUの統合を含みます。部品工場の製造プロセスは、Tier-1間で異なる場合があります。生産に費やされる時間は、OEMとTier-1にとって重要かつコストがかかるため、最小限に抑える必要があります。

証明書と鍵のセキュアな管理のために、これらの基本的な目標を導き出すことができます。

図1: 車両ライフサイクル全体の保護

車両のセキュリティは、そのコンポーネントの製造から始まります。コンポーネントが製造されると、耐タンパー性を提供する一意のIDが与えられます。それらのセキュリティが、車両全体の完全なセキュリティにつながります。自動運転、電動化、共有、コネクテッドなどの技術を可能にするため、車車間・路車間通信は保護されます。

2番目に非常に困難なユースケースは、車両のサービスと修理です。特に、新品の純正電子スペアパーツへの部品交換は、セキュアなソリューションの複雑さを増します。

誰もが正規ディーラーに依頼したり、純正交換部品を使用したりしない可能性もあります。車両コンポーネント間の信頼関係を回復するには、新しい電子スペアパーツを車両に安全に取り付ける必要があります。これには、例えば、自動車製造工程で最初にその車両識別番号（VIN）に挿入されたキーを検索し、新しい電子スペアパーツに安全に挿入するなど、機密性の高い操作が必要です。これにより、車両のすべてのキーを一貫した状態に更新できます。
次のセクションでは、OEMの状況についてさらに詳しく説明します。

状況と進化の道筋

証明書と鍵のプロビジョニングにおいて、他のOEMよりも経験豊富なOEMもいるため、OEMは次のいずれかの状態にあることがわかります。

我々は通常、2つの異なるルートを見ます。OEMは最初に証明書用のソリューションを作成するか、（対称）鍵用のソリューションを先に作成します。もう一方の側面は、この最初のステップの後に統合されます。両方のサポートを同時に導入するところはほとんどありません。

最初のステップ（AからBまたはCへの移行）が最も労力を要することは明らかです。デバイスを信頼し、ECUを車両にバインドし、同じ車両内のECU同士を信頼させるためのインフラストラクチャを作成する必要があります。
OEMがすでに個別の証明書をサポートしているが、まだ対称鍵をサポートしていない場合（B）、このサポートを追加することはそれほど難しくありません。既存の証明書と基礎となる非対称鍵を使用して、ECUにインストールする必要がある対称鍵を簡単に暗号化および署名できるためです。
OEMがすでに対称鍵をサポートしているが、証明書をサポートしていない場合（C）、ECUへの信頼がすでに確立されているため、証明書のサポートを追加することは難しくありません。この信頼に基づいて、証明書署名要求（CSR）を作成し、証明書を生成できます。あるいは、秘密鍵と証明書を（対称）鍵と同じ方法で注入することもできます。
これらの進化のステップにはバックエンドシステムの変更も含まれるため、この
証明書と鍵の管理ソリューションに柔軟性を持たせることが、OEMの能力の進化において不可欠になることは明らかです。さらに、この柔軟性は、関連するアルゴリズムや鍵を変更したり、車両に新しいユースケースを追加したりするために不可欠です。

3. MACsecによるイーサネット通信の保護

このセクションでは、キーを安全にインストールする必要がある車載セキュリティ機能の例としてMACsecを使用します。私たちが示す洞察の多くは、他のセキュリティ機能にも適用できるはずです。
車載イーサネットの導入により、車載通信用の最初の真に統合された通信技術が利用可能になりました。CAN、FlexRay、LIN、MOSTのような以前の既存の自動車通信技術と比較して、初めて音声、ビデオ、インターネットトラフィック、および車載制御トラフィックを同じ通信技術で伝送することが可能になりました。車載イーサネットの柔軟性と機能は、革新的な車両アーキテクチャを開発する上でゲームチェンジャーとなりますが、同時に、車載イーサネットのセキュリティは非常に重要です。幸いなことに、既存のセキュリティ技術を車両のユースケースに適合させることができ、車載イーサネットが車載通信技術のベンチマークになることを可能にします。
今日使用されているSecOC、IPsec、（D）TLSなどのセキュリティソリューションは、メッセージの多くの部分や、例えばレイヤー2プロトコルなどが簡単には保護できないため、外部攻撃者からの通信を部分的にしか保護できません。このため、自動車の文脈で導入されている最も有望なセキュリティソリューションは、すべてのイーサネット通信を保護するためのIEEEベースのプロトコルであるMACsecです※1。

※1：IEEE Computer Society, Media Access Control (MAC) Security, IEEE Standards Association, 2018.

MACsecは、車載イーサネット上のほぼすべての通信に対してハードウェアベースの保護をサポートします。ISO/OSIレイヤー2、つまりデータリンク層またはメディアアクセス制御層で通信を保護するため、MACsecという名前が付けられています。これは、図3に示すように、いわゆるSecTagと完全性チェック値（ICV）でイーサネットメッセージを保護することによって実現されます。

図3: MACsec SecTagとICV

SecTag 自体は、通信を保護するための重要なメタデータ (各イーサネット フレームに番号を付けるために使用されるパケット番号 (PN) など) を持ち、攻撃者が MACsec で保護されたフレームを簡単に再生できないようにします。

MACsecは、車載イーサネット上の通信に対してハードウェアベースの保護をサポートします。

MACsecによって追加されたICVは、イーサネットフレーム全体を改ざんから保護し、いわゆるセキュアアソシエーションキー（SAK）を使用します。メッセージが転送中に変更されていないことを保証するためです。MACsecは、ICVを作成するためにGCM-AES-256のようなさまざまな暗号アルゴリズムをサポートしています。MACsecは、必要に応じてイーサネットフレームのペイロードをさらに暗号化することができます。
MACsecが安全に動作するためには、通信を開始するときにイーサネットリンク上のすべての通信パートナーにSAKが存在している必要があります。異なる起動時や異なる車両でSAKを再利用することは安全ではないため（リプレイ保護）、MACsecは、起動時に新しいSAKを生成するために使用されるMACsecキーアグリーメントプロトコル（MKA）によって補完されます。次のセクションでは、MACsecキーアグリーメントプロトコルについて詳しく説明します。

MKAプロトコルを使用したMACsecキーアグリーメント

MACsecキーアグリーメントプロトコル（MKA）は、起動時にMACsec用の新しいセッションキー（SAK）を生成するために作成されました。ほとんどのキーアグリーメントプロトコルと同様に、MKAは、通信パートナーに存在する必要がある暗号アーティファクトによって、関係者間の信頼を確立する必要があります。

図4は、MKAとMACsecがどのように相互作用するかを詳述し、さらにオプションの拡張認証プロトコル（EAP）を示しています。EAPは、キー、証明書、またはハードウェアトークンなどのさまざまなセキュリティアーティファクトに基づいて、起動時にコネクティビティアソシエーションキー（CAK）を生成するために使用できます。あるいは、CAKをECUに挿入して永続的に保存することもできます。
CAKを使用すると、MKAは通信ピアとキーアグリーメントを実行し、MACsecを実行するために必要なSAKを生成できます。CAKを直接挿入することは可能ですが、SAKを生成しないとMACsecはリプレイ攻撃に対して安全ではなくなります。したがって、MKAはオプションではありません。

図4: MACsec、MKA、およびキー

EAPとMKAを使用すると、認証とキーアグリーメントは、さまざまな暗号アーティファクトとメカニズムに基づかせることができます。さらなる議論のために、表1でOEMが選択する最も一般的な3つのオプションを検討します。

• CAKは、長期的な秘密として通信パートナーに存在する場合があります。
• 適切なEAPモジュールを使用して、起動ごとにCAKを生成することができます。適切なEAPモジュールには、EAP-TLSやEAP-IKEv2が含まれ、X.509証明書を使用してすべての通信当事者を認証できます。
• 例えば証明書を使用してMKA用のCAKを生成し、キャッシュするカスタムEAPモジュール。これにより、時間のかかる非対称暗号は一度だけ実行すればよくなります。

表1: CAKを供給するためのソリューションと一般的なパフォーマンス数値の比較

これらの異なるオプションにはそれぞれ異なる利点があります。CAKを直接インストールすると、複雑さを最小限に抑えながら、成熟したソリューションが使用され、最高のパフォーマンスが得られます。既存のEAPモジュールを使用すると、複雑さが増し、より多くのリソースが必要になるため、起動時の遅延が長くなります。起動時の遅延が長くなる原因は、追加の（非対称）暗号操作が必要になるためです。妥協案として、生成されたCAKを使用するカスタムEAPモジュールを適用することができます。これにより、高コストな操作は初回使用時のみで済みます。

このような明確な利点があれば、すべてのOEMが、車両内での複雑性が最も低く、パフォーマンスが最も優れた「直接インストールされたCAK」を選択すると予想されるでしょう。しかし、このオプションは、車両に対称鍵をインストールする機能を必要としますが、この機能はまだすべてのOEMでサポートされているわけではありません。したがって、この問題を解決するための一つの代替案は明らかです。OEMは対称鍵プロビジョニングのサポートを導入することができます。これは最初は（特にバックエンドの）オーバーヘッドが増えるように見えますが、OEMは他の機能（例：SecOC）のためにこの機能を統合する必要があることが示されており、適切な証明書と鍵のプロビジョニングソリューションがあれば、この機能を追加するオーバーヘッドは驚くほど低くなります。

4. まとめ

車両アーキテクチャにMACsecを導入する場合、CAKがMKAにどのように供給されるかを選択することが不可欠です。パフォーマンス、成熟度、複雑性、およびリソースに基づいて最適なソリューションは、事前共有された対称CAKであり、証明書を使用するとパフォーマンスが悪化したり、複雑性やリソース使用量が増加したりすることが示されました。
このページで示したように、MACsecとMKAを証明書で動作するように適応させることは可能ですが、証明書と鍵のプロビジョニングを調整する方がより効果的なソリューションです。
したがって、柔軟で高性能な証明書と鍵のプロビジョニングシステムは、コスト効率が高く最も安全な車両を設計するための重要な礎石です。その結果、MACsecなどの重要なセキュリティソリューションの迅速な展開が可能になります。

Technica Engineeringについて
Technica Engineeringは、ミュンヘン（ドイツ）に本社を置くグローバルな自動車エンジニアリング企業です。
Technicaは2008年にテスト会社としてスタートし、初期から車載イーサネットおよび車載イーサネット製品に注力してきました。その後、セキュリティおよびシステムエンジニアリングがコアコンピタンスに追加されました。2022年、TechnicaはKPIT Technologiesに買収されました。KPIT Technologiesは、ソフトウェア定義車両の実現に向けて、自動車およびモビリティエコシステムへのグローバルパートナーです。2018年に初の車載MACsecデモを発表した後、Technicaは今日、車載MACsecのコンセプト、要件、プロトタイプ、テスト、および製品を提供するリーディングカンパニーの1つです 。700人以上のエンジニアを擁するTechnicaは、世界中の著名なOEM向けに、テスト、車載イーサネット、ネットワークセキュリティ、およびE/Eアーキテクチャのサービスと製品を提供する、推奨サプライヤーの1つです。

UTIMACOについて
UTIMACOは、アーヘン（ドイツ）とキャンベル（米国カリフォルニア州）に本社を置く、信頼性の高いサイバーセキュリティおよびコンプライアンスソリューションとサービスのグローバルプラットフォームプロバイダーです。
UTIMACOは、オンプレミスおよびクラウドベースのハードウェアセキュリティモジュール、キー管理、データ保護、ID管理のためのソリューション、ならびに規制された重要インフラや公共警報システム向けのデータインテリジェンスソリューションを開発しています。UTIMACOは、その主要な市場セグメントにおいて世界をリードするメーカーの1つです。世界中の500人以上の従業員が、グローバルな顧客と市民に対する責任を持って、データ、ID、通信ネットワークを保護するための革新的なソリューションとサービスを創造しています。さまざまな業界の顧客やパートナーは、UTIMACOの高セキュリティ製品とソリューションの信頼性と長期的な投資セキュリティを高く評価しています。

本ページはUtimaco社「Key Provisioning as Foundation for Automotive MACsec」を翻訳したものです。

著者
Priyank Kumar
Sr. Director Automotive / IoT & Payments
Utimaco GmbH Germanusstraße 4
52080 Aachen, Germany priyank.kumar@utimaco.com

Dr. Lars Völker
Technical Fellow and Head of Media Relations
Technica Engineering GmbH Leopoldstraße 236
80807 München, Germany lars.voelker@technica-engineering.de