Androidマルウェアによるシステム改ざんを検知する技術「セキュアブート」「dm_verity」とは：Androidセキュリティ技術の最前線（6）（3/3 ページ）

dm_verityによるシステム領域の保護

　このsystem.imgの検証に伴う2つの問題を解決するため、Android 6.0から必須機能として導入された技術が、「dm_verity」である（関連リンク）。dm_verityでは、system.imgを4キロバイト単位のブロックに分割して、各ブロックのハッシュ値をツリー形式で構成した「Hash Tree」を事前に計算しておく（図5）。そしてこのHash Treeから作成したサイズの小さいメタデータの一部（dm_verity_table）だけをセキュアブートの検証対象とすることで、system.img全体を検証する場合に比べて、起動時間を現実的な時間内に短縮する。

図5　dm_verityのHash Tree（出典元：Google）

　また、Hash TreeそのものはAndroid起動時には検証されないが、Android実行中にファイルシステムへの読み込みが発生した際には、Hash Treeを動的に計算して完全性をチェックする。これにより、改ざんを検出できるようになっている。

　さらにAndroid 6.0では、ブロックレベルの完全性を検証するdm_verityの設計に合わせて、OTA更新パッチも、ビットレベルの同一性を確保するために、ファイルレベルからブロックレベルに変更されている。dm_verityのフローを整理すると、以下のようになる（図6）。

図6　dm_verityのフロー

• 端末製造時

図7　dm_verity有効化時のsystem.imgのフォーマット（青色が通常のsystem.img、緑色がdm_verityによる追加部分（橙色を含む）、橙色が起動時の署名検証で使用する部分）

• 端末起動後

　dm_verityが適用されたシステムにおいてユーザーは、マルウェアによる単純な/systemのファイル書き換えを、読み込んだブロックのハッシュ検証失敗によるI/Oエラーで検知することができる。一方で、マルウェアがdm_verityを前提として、バイナリレベルでブロックと対応するHash Treeを書き替えた場合には、起動時のroot hashの署名検証で改ざんを検知できる。また、ブロックのハッシュ値がHash Treeの対応するハッシュ値と同じになるようなブロックの値を作り出すことは、暗号学的に困難であることが知られている。

　このようにAndroid6.0からは、dm_verityとセキュアブートを組み合わせることで、Linuxカーネルだけでなく、Androidシステム層までも含めて、改ざんの検証を行うことができるようになった（図8）。

図8　セキュアブートとdm_verityによるAndroidの保護

Googleによるブートフローのガイドライン

　さて、ここまで、Androidの起動時にシステムの完全性を検証することでAndroid端末の安全性を保証する仕組みについて解説してきた。しかし、もしシステムが改ざんされていることが分かったとして、どのようなアクションを取ればよいのだろうか？ 「システム改ざんが検出された時点で起動処理を中止する」という対応がまず考えられるが、ユーザーから見れば端末がなぜ起動しないのか分からないため、混乱を導く恐れがある。

　そこで、セキュアなブート処理において考慮すべきフローについて、GoogleからVerified Bootとしてガイドラインが公開されている。例えば、OSカーネルやdm_verity_tableがセキュアブートに失敗したときには、赤色の警告で検証に失敗した旨を表示することが推奨されている（図9）。

図9　Verified Bootにおける警告（出典元：Google）

　現在販売されている全ての端末がこの新しいガイドラインに準拠しているわけではないが、今後発売される端末はこのVerified Bootに対応していくものと考えられる。これらの仕組みが活用されれば、システム改ざんを伴うような巧妙化したマルウェアへの感染にユーザーが容易に気付けるようになり、被害の拡大を防ぐことができるだろう。