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

» 2016年08月03日 05時00分公開

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のフロー

端末製造時

端末ベンダーは、準備として公開鍵ペア（公開鍵PuKと秘密鍵PrK）を生成する
端末ベンダーは、system.imgを4キロバイトごとのブロックに分割し、ハッシュ関数（SHA-256）を使って図5のようなHash Treeを構成する
端末ベンダーは、Hash Treeを基にdm_verity_tableを作成する（図7）
端末ベンダーは、公開鍵暗号を使った署名アルゴリズムを用いて、dm_verity_tableの署名を秘密鍵PrKで生成する
端末ベンダーは、system.imgにメタデータ（dm_verity_tableおよび署名）とHash Treeを結合し（図7）、ROMに書き込むとともに、公開鍵PuKをboot.img内（Ramdiskの/verity_key）に書き込む。boot.imgには、公開鍵PuKを含むセキュアブートの署名が生成される

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

端末起動後

boot.imgがセキュアブートされ、OSカーネルとして起動する。検証された公開鍵PuKとsystem.imgのメタデータ（root hashおよび署名）を使って署名を検証し、正しければFileSystem/systemにマウントする。boot.imgからsystem.imgへと信頼の連鎖（Chain of Trust）が構築される
FileSystem/systemが読み出されるたびに、ブロックごとにroot hashまでのHash Treeとのハッシュ検証を行う。ハッシュ値が違うときにはI/Oエラーを返す

　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に対応していくものと考えられる。これらの仕組みが活用されれば、システム改ざんを伴うような巧妙化したマルウェアへの感染にユーザーが容易に気付けるようになり、被害の拡大を防ぐことができるだろう。