FIA の研究

この論文を参考にしながら FIA について言及します．

Figure.10 がもっとも概観できるのではないでしょうか

この論文では FIA を以下の 2 つの軸で見ています．

• Fault Modeling
  • Injection の手法を分類する
• Fault Analysis
  • 結果の解析を分類する

Fault Modeling

• Voltage Glitching：電圧を意図された正常範囲の外へ短時間だけ遷移させる攻撃．
  • Underpowering：IC の電圧を規定値よりも下げる手法．実行が比較的簡単だが，供給電圧が IC 全体に影響するため，狙った Fault が難しい．
  • Negative Power Supply Glitching：より鋭い波形で電圧降下を起こす．
  • Positive Power Supply Glitching：減衰振動を誘発して間接的に電圧を規定値に落とす．
• Clock Glitch：正常なクロックの周波数から逸脱した短い信号を入れる
  • Precisely Timing：決定的で再現性がある一方で，タイミングの整合がむずかしい
  • Fuzzy Glitch：ランダムにクロック信号を生成するので簡単だが，総当たり的なので再現性がない
• RowHammer：プロセッサではなくメモリ（DRAM）における電圧グリッチ
• Laser FI：レーザーを用いたビット変換を引き起こす．位置解像度が高いが，高価．低コストなレーザー FI も研究されているが，最近は飽和しつつある
• EMFI：短い電磁エネルギーを IC に与える攻撃．安価で局所的ではあるものの，レーザーよりも解像度は低い．

Fault Analysis

• Set Fault：対象ビットを 1 に変える
• Reset Fault：対象ビットを 0 に変える
• Bit-Flip Fault：対象ビットをひっくり返す

さらに論文では，抽象度が上がるにつれてエラーがどう解釈されるかも説明しています． バイナリ内の破損したビットは，機械語のオペコードやオペランドの改変として解釈され， 次に LOAD/STORE 命令のデータ破損や NOP による意図しない命令スキップとしてアセンブリレベルで解釈され， 最終的にプログラムレベルでの制御フローの乗っ取りや完全性の破壊として伝搬します．

最終的にこれらは，暗号解析，論理攻撃，リバースエンジニアリングとしてあらわれます．

Limitation of Problem

ここまではどのように攻撃・解析するかでしたが，論文の後半ではどのように脆弱性を見つけ，どのように守るかにつながります． まず論文が言及しているのは，脆弱性検出ツールの限界です．

FIA の脆弱性検出には，シンボリック実行や Fuzzing といったプログラム解析技術が使われています． 中でもシンボリック実行は，変数を記号のまま扱って全実行パスを網羅的に探索できる点が強みです． 一方で，直感的に探索すべき空間が巨大になって検査時間が長くなることが分かります．

さらに根本的な問題として，単純な fault primitive だけで検査すると，ほぼすべての行が脆弱だと判定されてしまいます． 例えば bit-flip では，バイナリのほぼすべてが攻撃対象になるからです． 論文はここから，「物理的・論理的に意味のある範囲へ問題空間を絞り込む，現実的なモデリング制約が必要だ」と言及します． つまり，ハードウェア側とソフトウェア側のふるまいの橋渡しをする，より現実的な fault model が今後の課題だということです．

Countermeasures（対策）

論文は対策の難しさを示しています．

脅威モデル

FIA は「ハードウェアが正しく実行してくれる」という前提を崩す攻撃で， Fault Modeling → Injection → Manifestation（回路のエラー）→ Propagation（ソフトのエラー）→ Observation（挙動変化の観測）→ Exploitation（悪用）の6段階に分けています． 対策の目標は，このいずれかの段階を検知・防止・緩和することです． 厄介なのは，FIA は既存のバグを必要とせず動的にバグを作り出せる点，そして対策そのものが FIA の標的になりうる点です． 攻撃の狙いは大きく暗号解析・論理攻撃・リバースエンジニアリングの3つで，対策とは要するにこれらの達成コストと難度を引き上げることです． たとえば「短時間に似たフォールトを複数回入れさせる」よう強制できれば，複数グリッチの同時最適化は一般に複雑すぎて攻撃は非現実的になります．

ソフトウェア対策

• Detection ベース：冗長性をもたせる，命令の反復で誤りを検出する
• Infection ベース：注入された誤りを撹乱し，故障出力から意味ある情報を復元できないようにする

ソースコードがないバイナリ向けに，実行ファイルを書き換えて対策を自動挿入する手法や， RowHammer 向けに，頻繁アクセスされる行を検出して被害行をリフレッシュする手法もあります． ただしソフト対策は性能コストが大きく，望ましくない副作用も伴います．

ハードウェア対策

こちらも空間／時間／情報の冗長化が基本で， 最も一般的なのは機密ビットを複数回読み出して故障値を無視する方式です． そのほか，レーザーによる周波数擾乱を自動検知するゲートレベル対策や， サイドチャネルと DFA の双方に効く WDDL（Wave Dynamic Differential Logic）などがあります． 論文は，ソフトウェアだけで守るのは非現実的であり，ハードウェア自体の堅牢化が必要であると言及しています．

参考

SoK: A Beginner-Friendly Introduction to Fault Injection Attacks
Console Security -