Androidマルウェアによるシステム改ざんを検知する技術「セキュアブート」「dm_verity」とは：Androidセキュリティ技術の最前線（6）（3/3 ページ）
Androidセキュリティをめぐる最新の状況を、各界のエキスパートたちが解説する本連載。今回はシステム改ざんを行うようなAndroidマルウェアを検知する技術を紹介する。
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全体を検証する場合に比べて、起動時間を現実的な時間内に短縮する。
また、Hash TreeそのものはAndroid起動時には検証されないが、Android実行中にファイルシステムへの読み込みが発生した際には、Hash Treeを動的に計算して完全性をチェックする。これにより、改ざんを検出できるようになっている。
さらにAndroid 6.0では、ブロックレベルの完全性を検証するdm_verityの設計に合わせて、OTA更新パッチも、ビットレベルの同一性を確保するために、ファイルレベルからブロックレベルに変更されている。dm_verityのフローを整理すると、以下のようになる（図6）。
- 端末製造時
- 端末ベンダーは、準備として公開鍵ペア（公開鍵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を含むセキュアブートの署名が生成される
- 端末起動後
- 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）。
Googleによるブートフローのガイドライン
さて、ここまで、Androidの起動時にシステムの完全性を検証することでAndroid端末の安全性を保証する仕組みについて解説してきた。しかし、もしシステムが改ざんされていることが分かったとして、どのようなアクションを取ればよいのだろうか？ 「システム改ざんが検出された時点で起動処理を中止する」という対応がまず考えられるが、ユーザーから見れば端末がなぜ起動しないのか分からないため、混乱を導く恐れがある。
そこで、セキュアなブート処理において考慮すべきフローについて、GoogleからVerified Bootとしてガイドラインが公開されている。例えば、OSカーネルやdm_verity_tableがセキュアブートに失敗したときには、赤色の警告で検証に失敗した旨を表示することが推奨されている（図9）。
現在販売されている全ての端末がこの新しいガイドラインに準拠しているわけではないが、今後発売される端末はこのVerified Bootに対応していくものと考えられる。これらの仕組みが活用されれば、システム改ざんを伴うような巧妙化したマルウェアへの感染にユーザーが容易に気付けるようになり、被害の拡大を防ぐことができるだろう。
著者プロフィール
▼古川 和快（ふるかわ かずよし）
株式会社富士通研究所 知識情報処理研究所 セキュリティ研究センター
暗号理論のソフトウェア・ハードウェア実装、モバイル機器のシステムセキュリティや製造開発におけるセキュリティ、サイバーセキュリティ対策技術の研究開発に従事。
▼兒島 尚（こじま ひさし）
株式会社富士通研究所 知識情報処理研究所 セキュリティ研究センター
Javaを中心としたソフトウェアセキュリティ、Webアプリケーションセキュリティ、組み込み機器のセキュリティ、セキュリティテストなど、情報セキュリティ関連の研究開発に従事。OSや実行環境、ネットワーク製品などのセキュリティ脆弱性の報告多数。
Copyright © ITmedia, Inc. All Rights Reserved.