使用例

このドキュメントでは、AVF の一般的なユースケースについて説明します。

分離されたコンパイル

保護された VM はソフトウェア セキュア エンクレーブとして、セキュリティの影響を受けやすいコードをコンパイルするための安全な環境を提供します。この環境では、bootclasspath とシステム サーバー JAR（APEX アップデートによってトリガーされる）のコンパイルをアーリーブートから再起動前に移動でき、APEX 更新後の起動時間が大幅に短縮されます。

実装は com.android.compos APEX にあります。このコンポーネントはオプションであり、makefile を使用して追加できます。

分離されたコンパイル

図 1. メインラインの更新で JAR をコンパイルする

セキュリティの目標は、検証された入力を正しくコンパイルし、出力を単独で生成することです。信頼できないクライアントとして、Android はエラーを引き起こす以外の方法でコンパイル出力を変更できません（Android が起動時コンパイルにフォールバックする場合）。

VM のコンパイル サービスは、コンパイル中にエラーがない場合にのみ署名を生成します。Android は、署名検証のために VM から公開鍵を取得できます。

VM の鍵は、VM にマウントされている APEX と APK で定義された VM の DICE プロファイル、およびデバッグ可能性などの他の VM パラメータによって生成されます。

公開鍵が予期しない VM からのものかどうかを判断するために、Android は VM を起動して鍵が正しいかどうかを判断します。APEX が更新されるたびに、VM はアーリーブートで起動します。

保護された VM の確認付きブートを使用すると、コンパイル サービスは確認済みのコードのみを実行します。したがって、コードは、特定の条件（たとえば、名前と fs-verity ダイジェストが許可リストで定義されている場合のみ入力ファイルを受け入れるなど）を満たす入力のみを受け入れるかを判断できます。

VM から公開される API はすべて攻撃対象になります。すべての入力ファイルとパラメータは、信頼できないクライアントからのものと見なし、処理前に検証と審査を行う必要があります。

入出力ファイルの整合性は VM によって検証されます。信頼できないファイル サーバーとして Android に保存されているファイルは次のように処理されます。

  • fs-verity アルゴリズムを使用して、入力ファイルを使用する前に内容を確認する必要があります。入力ファイルを VM で使用できるようにするには、VM の DICE プロファイルに寄与するコンテナ（APK）にルートハッシュを指定する必要があります。信頼できるルートハッシュにより、入力を改ざんする攻撃者が検出されます。
  • 出力ファイルの整合性は VM 内で維持する必要があります。出力ファイルが Android に保存されている場合でも、生成時に整合性は同じ fs-verity ツリー形式で維持されますが、動的に更新できます。最終出力ファイルは、VM で分離されたルートハッシュで識別できます。VM 内のサービスは、署名によって出力ファイルを保護します。