車載ECUを守る：サイドチャネル攻撃に対する実践的ソフトウェア対策

サイドチャネル解析（SCA）攻撃とは、ROMの読み取りやソフトウェアのリバースエンジニアリングなどの直接的な解析を必要とせず、暗号処理の実行中に発生する電力消費などの物理的・副次的な信号を観測することで、自動車のECUに格納された暗号鍵などの機密情報を抽出する手法です。すでに車両コンポーネントに対するSCA攻撃は実証されており、現実的な脅威となっています。

一方で、現在市場に出回っている多くのECUは、こうした攻撃に対して十分な対策が施されていないケースも少なくありません。その背景には、車載ECU特有の長い開発サイクルや、設計確定後に新たなハードウェアセキュリティを追加することの難しさがあります。理想的にはハードウェアレベルでの対策が望ましいものの、既存のシステムに後付けで適用することは現実的ではありません。そのため、既存ECUに対してはソフトウェアによる対策が重要な選択肢となります。例えば、暗号処理の実行回数を制限する、処理にランダム性を導入してパターンを不明瞭にする、あるいはマスキング技術を活用するといった手法が挙げられます。

ただし、これらの対策を導入する際には注意が必要です。車載の組み込みシステムはCPUやメモリに厳しい制約があるため、セキュリティ強化とシステム性能とのバランスを慎重に見極めることが、自動車メーカーにとって重要なポイントとなります。

はじめに

現代の車両は、組み込みソフトウェアを実行する複数のECUのネットワークによって、重要な機能を実現しています。車両のコネクティビティが進展し、セキュリティ要件がますます高まる中で、暗号技術の活用は急速に広がっています。その結果、暗号アルゴリズムそのものの強度だけでなく、暗号の実装方法という点も、同等に重要な要素となっています。

サイドチャネル解析（SCA）は、暗号処理の実行中に生じる電力消費や電磁放射といった物理的な副次情報から、意図せず漏えいする機密情報を利用するサイバー攻撃の一種です。従来のように暗号アルゴリズムを数学的に解読するのではなく、実装上の挙動を突くことで情報を取得するという点がこの攻撃の特徴です。

サイドチャネル解析（SCA）とは何か

組み込みシステムに対する物理攻撃の文脈において、サイドチャネル解析（SCA）攻撃とは、組み込みプロセッサ内部での処理の実行状況に関する情報を悪用する手法です。具体的には、暗号処理の実行中にチップの電源ラインや電磁放射などの外部に漏れ出る情報を観測し、そこから暗号鍵などの機密情報を抽出することを目的としています。

では、SCA攻撃がどのように行われるのか、具体例を見てみましょう。あるプロセッサが、秘密鍵を用いて暗号処理を実行できるとします。このとき攻撃者は、暗号処理の実行中に発生するサイドチャネル（例えば電力消費）を計測するための装置を用意します。同時に、攻撃者は暗号処理を繰り返し実行させる手段も持っています。多くのSCA攻撃では、同一の処理を何度も計測することで、鍵情報を統計的に抽出する必要があるためです。

一般的な攻撃環境では、オシロスコープなどの計測機器を用いて、暗号処理中の電力消費の変化（トレース）を記録します。さらに、CANメッセージの送信などを通じて、対象となる暗号処理を繰り返しトリガーします。このプロセスを数千回から数百万回にわたって実行することで、解析に十分なデータを収集し、最終的に機密情報の復元を試みます。

収集したトレースデータは、その後オフラインで統計的手法を用いて解析され、鍵に依存する情報の抽出に利用されます。

SCAアルゴリズムの種類と仕組み

ここではSCAの電力解析を用いた攻撃手法について解説します。電力解析を用いたSCAには、複数の代表的なアルゴリズムが存在します。いわゆるクラシックな手法としては、Simple Power Analysis（SPA：単純電力解析）、Differential Power Analysis（DPA：差分電力解析）、Correlation Power Analysis（CPA：相関電力解析）が広く知られています。さらに、Mutual Information Analysis（MIA：相互情報解析）やディープラーニングを活用したDL-SCA、テンプレート攻撃など、より高度な手法も存在します。

では、これらのアルゴリズムはどのように機能するのでしょうか。例えば、AES（Advanced Encryption Standard：共通鍵暗号方式）に対するDPA攻撃では、攻撃者は鍵の候補ごとにAESのSubBytes処理の出力に関する特定の性質（例えば、特定ビットが0か1か）を予測し、それに基づいて電力トレースをグループ分けします。次に、これら2つのグループの平均トレースを比較し、差分を計算すると、正しい鍵候補の場合には特徴的なピークが現れ、対象となる鍵ビットを特定する手がかりとなります。一方で、誤った鍵候補では、この差分は理想的には平坦な結果になります。

アルゴリズムによっては、鍵とサイドチャネルデータとの間の相互情報量など、異なる統計的指標を用いて解析を行います。そのため、攻撃成功に必要なトレース数にはばらつきがあり、比較的単純な手法では、対象によってはどれだけデータを収集しても十分な結果が得られない場合もあります。こうして暗号鍵が抽出されると、その後の攻撃に悪用される恐れがあります。例えば、ECUの診断機能への特権アクセスを取得してコード実行を行ったり、デバイスのなりすまし、あるいは他のセキュリティ制御の回避といったシナリオにつながる恐れがあります。どのような攻撃が成立するかは、取得された秘密鍵の用途や対象システムに依存します。

自動車分野におけるSCAの脅威

SCA攻撃は、すでにさまざまな車載ECUに対して実行可能であることが実証されています。例えば、イモビライザーシステムの無効化、キーフォブ（スマートキー）の認証方式の解読、さらにはCAN通信の認証鍵の抽出などにSCAが利用できることが報告されています。

一方で、SCA攻撃に対して有効なハードウェアベースの対策技術は存在しているにもかかわらず、現在市場に出回っている多くの車載ECUでは、この脅威に対する十分な防御が実装されていないのが実情です。

その背景には、いくつかの要因が考えられます。

• ECUの設計は市場投入の数年前から始まることが一般的であり、多くの場合、当時の「一世代前」のアーキテクチャや設計に基づいて開発されます。その結果、セキュリティの観点では最新の脅威に対して追いついていないケースが少なくありません。
• 既存のアーキテクチャに後付けでセキュリティ機能を組み込むことは容易ではなく、とりわけ新たなハードウェアの追加を伴う場合、その難易度はさらに高くなります。
• ISO/SAE 21434に基づくリスクアセスメントを実施している場合でも、SCA攻撃の影響範囲や実行の容易さが十分に評価されていないことがあり、その結果、この領域におけるセキュリティ要件が不十分または欠如しているケースも見受けられます。

特に、以下のようなECUは、SCA耐性を備えることが強く求められます。

• ボディコントロールモジュール（BCM）／イモビライザー 車両盗難防止に直結する鍵情報を直接保持する重要なコンポーネントです。
  
  
• ゲートウェイECU
  CANやEthernetなど、異なる車両ネットワーク間の通信を仲介する役割を担い、メッセージ認証や暗号化に使用される重要な鍵を保持します。
  
  
• テレマティクスコントロールユニット（TCU） OTAやセルラー通信など外部接続を担うユニットであり、リモート攻撃の起点となりやすい領域です。安全な通信やソフトウェア更新に必要な鍵を管理しています。

ソフトウェアによるSCA対策

すでに市場に出ている、あるいは主要なアーキテクチャ／設計が完了しているECUにおいて、AES暗号処理に対するSCA対策が必要になった場合を考えてみましょう。このようなECUはソフトウェアを更新する手段は備えているものの、SCA耐性を持つハードウェアへの変更は現実的ではない場合がほとんどです。

では、ソフトウェアレベルでどのような対策が可能でしょうか。特に電力解析のようなSCA攻撃に対しては、いくつか有効なアプローチが存在します。

ソフトウェアベースの対策は、大きく分けて以下の戦略に整理できます。SCA攻撃は「鍵に関連する情報がサイドチャネルに漏えいする」ことを前提としているため、その前提を崩すことが対策の基本的な考え方となります。

• 取得制限（Acquisition Limiting）攻撃者が十分な数のトレースを収集できないように制御する手法です。例えば、暗号処理の実行回数に制限を設けることで、統計解析に必要なデータ量の確保を困難にします。
  
  
• ハイディング（Hiding）サイドチャネルに現れる信号のパターンを不明瞭にし、解析を困難にする手法です。具体的には、処理のタイミングをランダム化するなどして、SNR（Signal-to-Noise Ratio：信号対雑音比）の低下や同期ずれを起こして、鍵情報とサイドチャネルの相関を低減させます。
  
  
• マスキング（Masking）暗号処理中に扱う機密データをランダム化し、サイドチャネルから観測される情報と鍵との統計的な依存関係を断ち切る手法です。これにより、仮に情報が漏えいしたとしても、鍵そのものを推定することが困難になります。
  
  
  

これらの手法は単独でも一定の効果がありますが、実際のシステムでは複数の対策を組み合わせて適用することで、より高い耐性を実現することが重要です。

取得制限

対策	仕組み	実装コスト (CPU/RAM)	効果
レート制限	攻撃者が一定時間内に取得できる電力トレースの数を制限する	CPU／RAM／ROMへの影響はごく小さく、比較的軽微なコード修正で実装可能	1回のトリップで暗号化処理が少ないアプリケーションに限定的に適用できる。適用可能な場合には非常に効果的。特にDPAやCPAといった攻撃は大量のトレースを必要とするため、その前提を崩すことで高い防御効果が期待できる
リキーイング／セッション鍵	セッションごと、一定時間ごと、あるいはメッセージごとに新しい鍵を生成・使用することで、1つの鍵に対して収集できるトレース数を制限する	CPU負荷は一定程度増加しますが、RAM／ROMへの影響は比較的小さく、プロトコル側での対応が前提	すべてのシステムで適用できるわけではないが、適用可能な場合には非常に有効。DPAやCPAは同一鍵に対する大量のトレースを必要とするため、鍵を頻繁に更新することで攻撃の難易度を大幅に引き上げることが可能

ハイディング

以下の表は、ソフトウェアで実装可能な代表的なハイディング対策をまとめたものです。

対策	仕組み	実装コスト (CPU/RAM)	効果
命令シャッフリング	暗号処理内の独立した命令の実行順序をランダムに入れ替えることで、データ依存の処理タイミングを変動させる	ランダム化のためのロジックが必要となるためCPU負荷は増加するが、RAM／ROMへの影響は最小限	処理の時間的な位置が不定になるため、正確なタイミング同期に依存するSPAやDPA／CPAといった攻撃に対して高い効果を発揮。なお、実装には乱数生成器（RNG）が必要
ダミー処理／ランダム遅延	データに依存しないダミー処理（例：不要な読み書き、No Operation命令、ウェイト状態など）をランダムに挿入することで、トレース間のタイミングずれ（非同期化）を引き起こす	CPUへの影響は軽微で、RAM／ROMの追加負担も最小限	SPAに対して有効であるだけでなく、トレースの同期を難しくすることでDPA／CPAの解析精度を低下させる。その結果、ノイズが増加し、攻撃に必要なトレース数を大幅に増やす効果が期待できる

ランダムマスキング

鍵情報がサイドチャネルに漏えいするのを防ぐためには、暗号処理において鍵をそのまま使用しないことが重要です。

ランダムマスキングは、機密データ（例えば秘密鍵）と物理的な漏えいとの直接的な関係を断ち切ることを目的とした手法です。具体的には、鍵に依存するすべての中間データをランダム化し、それらを複数の要素「シェア」に分割します。それぞれのシェア単体からは機密情報を推定できないように設計されているため安全性が向上します。

暗号処理は、このマスクされたシェアのみを用いて実行され、最終的な出力段階でそれらを再結合することで、本来の暗号結果を得ます。このようにすることで、サイドチャネルから観測される情報と実際の鍵との相関を大幅に低減することが可能になります。

以下は、AESに対する一次ブールマスキングの一例です。

前述の通り、最も基本的なマスキング手法（一次マスキング）は、以下のような手順で実装されます。

• 鍵と同じ長さのランダム値（rand）を生成する
• 鍵を2つのシェアに分割する：
  • s1 = rand
  • s2 = key XOR rand
• これらのシェアを用いて、マスクされた状態でAES演算を実行し、c1, c2 を得る
  （AESは非線形演算を含むため、内部処理ではシェア同士を組み合わせた計算が必要になります）
• 最後にアンマスキングを行い、シェアを再結合することで、通常のAES暗号結果 c を復元する
  
  
  

この例ではXOR演算を用いたブールマスキングが使われていますが、他にも加算型、乗算型、アフィン変換など異なる方式が存在し、それぞれ実装の複雑さや特性が異なります。

さらに、一次マスキング（2シェア）に加えて、より多くのシェアに分割する高次マスキングも利用可能です。シェア数を増やすことで耐性は向上し、より高度な攻撃への対策となります。

一方で、攻撃側も高次攻撃を実行することが可能です。この場合、各シェアに対するリーク情報を個別に解析し、それらを組み合わせて鍵情報を復元しようとします。ただし一般的には、「n次マスキングはn次攻撃に対して有効な防御となる」と考えられており、例えば一次マスキングは基本的なSCA攻撃（一次攻撃）に対して有効な対策です。加えて、高次攻撃は実装難易度が高く、必要なトレース数の増加、トレースごとの記録時間の増大、より精密な同期、低ノイズ環境の確保など、多くの制約があるため、現実的な攻撃のハードルは大きく上がります。

通常、このような対策には相応のコストが伴います。例えば、2つのシェアを用いたマスクAESの実行は、実質的に2回分のAES演算に近いリソースを消費します。さらに、暗号処理ごとに新たなランダム値の生成が必要となり、中間データを保持するための追加レジスタやメモリも求められます。以下の表では、マスキングを適用していない基本的なAES実装と比較しながら、各種マスキング手法におけるリソース要件（CPUサイクル、RAM、ROM）を示しています。緑は有利（低コストまたは高耐性）、赤は不利（高コストまたは低耐性）黄色はその中間を示します。

	必要なリソース			SCA攻撃成立のために必要な要件
	CPU サイクル (概算／ブロックあたり)	RAM	ROM	攻撃次数	トレース数
マスキングなし 基本的なAES実装（非対策状態）	~1.6k–2k	~0.5KB	~1-2KB	一次攻撃（基本的なSCA）	~1-7k（中程度のノイズ環境）
一次ブールマスキング	~x2–x10	~x2–x10	~x2–x10	二次攻撃	~1-7k（中程度のノイズ環境）, ~10-100k（高ノイズ環境）
二次ブールマスキング	~x10-x1000	~x5–x50	~x2–x10	三次攻撃	50-100k（中程度のノイズ環境） 100k-1m（高ノイズ環境）
一次乗算マスキング	~x2–x10	~x2–x10	~x2–x10	一次攻撃（攻撃者が入力を操作できる場合に成立）	~1-7k（中程度のノイズ環境）
一次アフィンマスキング	~x10-x100	~x2–x10	~x2–x10	二次攻撃	~50k-100k（中程度のノイズ環境） ~100k-1M（高ノイズ環境）

なお、上記の表に示した数値は、以下の各種公開情報や技術資料をもとに整理したものです。

[1] First-Order Masking with Only Two Random Bits

[2] All the AES You Need on Cortex-M3 and M4

[3] Affine Masking against Higher-Order Side Channel Analysis

[4] Review of Side Channel Attacks and Comparison of Masking and Re-keying Countermeasures

[5] Syn-STELLAR: An EM/Power SCA-Resilient AES-256 With Synthesis-Friendly Signature Attenuation

[6] Exploiting Small Leakages in Masks to Turn a Second-Order Attack into a First-Order Attack and Improved Rotating Substitution Box Masking with Linear Code Cosets

なお、表の数値は、公開されている実装例をもとにした概算であり、あくまで参考値として捉える必要があります。実際のリソース要件は、対象となるチップやアーキテクチャ、AESの実装方式（ビットスライス方式かテーブルベース方式かなど）によって大きく異なる点に留意が必要です。

実践的な対策のポイント

自動車メーカーおよびTier1サプライヤーとの取り組みを通じて得られた知見をもとに、サイドチャネル攻撃への対策における実践的なポイントを以下にまとめます。

• ソフトウェア対策の優先順位を見極める
  適切な対策を検討する際は、まずレート制限から検討することが有効です。これが適用できない場合、TCUやゲートウェイECUでは、ハンドシェイクやカウンタを伴う通信プロトコルが前提となっているため、セッション鍵の活用が現実的な選択肢となります。一方、イモビライザーやキーフォブのようなシステムでは、プロトコル制約や後方互換性の観点から、鍵のローテーションよりもマスキングの方が適しているケースが一般的です。
  
  
• 高品質な乱数の確保
  マスキングやシャッフリングを実装する際には、可能であればハードウェア乱数生成器（RNG）の使用が推奨されます。これにより、エントロピー不足を狙った攻撃や、低品質な乱数に起因する情報漏えいのリスクを低減できます。
  
  
• SCA評価の実施
  ECUのセキュリティ評価の一環として、SCAに対する耐性評価を実施することが重要です。特に、CPAやプロファイリング攻撃といった代表的な手法に対する検証を行うことで、実装の脆弱性を早期に特定し、対策の有効性を確認できます。

まとめ

サイドチャネル解析は、車載ECUに対して現実的かつ深刻なリスクとなり得る物理攻撃の一種です。こうした攻撃への対策が設計段階で考慮されていないECUであっても、ソフトウェアの更新が可能であれば、適切な実装によってリスクを低減することは十分に可能です。

一方で、これらのソフトウェア対策はセキュリティの観点では非常に有効である反面、CPU負荷やメモリ使用量の増加といったパフォーマンスへの影響を伴います。特にリソース制約の厳しい車載組み込みシステムにおいては、このトレードオフを十分に考慮しながら、最適な対策を選定・実装することが重要です。