Weaver

Android 8.1 で導入された Weaver Hardware Abstraction Layer(HAL)IWeaver.aidl)は、PIN、パターン、パスワードなどのロック画面知識要素(LSKF)を使用したユーザー認証のための安全なインターフェースを提供します。

Weaver は、 Gatekeeper の LSKF 検証機能に取って代わります。 ただし、ハードウェア認証トークンの生成には引き続き Gatekeeper が使用されます。 ハードウェア認証トークン

Android 9 以降では、 CDD 9.11.2 で、StrongBox をサポートするデバイスに、安全なユーザー認証をサポートする専用のセキュア ハードウェアを提供することが義務付けられています。このセキュア ハードウェアを使用して Weaver HAL を実装すると、「安全なユーザー認証」の要件を満たすことができます。

専用の セキュア エレメント(SE)がないデバイスでも、 Trusty などの高信頼実行環境(TEE)に Weaver を実装できます。

Android 17 以降では、専用のセキュア エレメントがないデバイスでも、Weaver を実装することを強くおすすめします。

コンポーネント

Weaver は次の 3 つのコンポーネントで構成されています。

  • Weaver AIDL インターフェース(IWeaver): HAL の正式な仕様。Android 13 以前では、AIDL の代わりに HIDL が使用されていました。
  • Weaver Hardware Abstraction Layer(HAL)サービス: `IWeaver` インターフェースを実装するベンダー固有の Android プロセス。
  • Weaver Trusted Application(TA): 安全な環境で実行されるコアロジック。LSKF の検証を行い 、レート制限を適用します。HAL サービスは、実装固有のセキュア チャネルを使用して TA と通信します。

インターフェース

Weaver のインターフェースは、固定サイズの鍵と固定サイズの値をそれぞれ含む、固定サイズの永続スロットの配列を提供します。各スロットは、[0, numSlots - 1] の範囲の整数である ID で識別されます。スロットの値にアクセスできるのは、保存されている鍵と一致する鍵が提供された場合のみです。

Weaver のインターフェースは主に次の要素で構成されています。

  • getConfig(): 実装でサポートされているスロット数、鍵のサイズ、 値のサイズを取得します。
  • write(): 指定したスロットを新しい Key-Value ペアで上書きします。このオペレーションはアトミックであり、以前のデータは完全に 復元できなくなります(安全な削除)。
  • read(): 指定したスロットの値を取得しようとします。 成功するのは、レート制限のタイムアウト(TA によって適用される) がアクティブではなく、提供された鍵が保存されている鍵と完全に一致する場合のみです。
  • warmUp(): Android 17 以降では、 読み取りまたは書き込みが間もなく発生する可能性があることを示すヒントを伝えます。

インターフェースの仕様の詳細については、 IWeaver.aidlをご覧ください。

Android での使用

Weaver の実装が利用可能な場合、Android システム サーバーの LockSettingsService はそれを使用してユーザーデータを保護します。デバイス上のユーザーごとに、LockSettingsService は Weaver スロットを管理します。

  • スロット鍵(weaverKey): ユーザーの LSKF のハッシュ。ユーザーが画面ロックを設定していない場合は、デフォルトの文字列が 使用されます。
  • スロット値(weaverSecret): エントロピーの高い、 ランダムに生成された暗号シークレット。

weaverSecret は、次のいずれかの場合にのみ取得できるように設計されています。

  • レート制限ポリシー内で Weaver TA に正しい weaverKey を提供する。
  • Weaver TA が実行される安全な環境を侵害する。これは 非常に困難なことです。

LockSettingsService は、weaverKeyweaverSecret の両方を使用して、ユーザーの合成パスワードを暗号化します。合成パスワードは、ファイルベースの暗号化(FBE)のユーザーの認証情報で暗号化された(CE)ストレージと、Android Keystore のユーザーの認証情報にバインドされた鍵を保護するため、Weaver がシークレットを解放するまでデータにアクセスできません。

Android 17 以降では、LSKF の入力が開始されると、LockSettingsService は Weaver の warmUp() メソッドを呼び出します。Weaver の実装では、このシグナルを使用して、今後の read() リクエストのレイテンシを短縮するために、セキュア ハードウェアを低電力状態から移行できます。

Weaver と Gatekeeper の比較

これまで、 Gatekeeper HAL は 1 回の verify() 呼び出しで 2 つの異なる役割を果たしていました。

  1. 検証: TEE 適用レート制限を使用して LSKF を確認します。
  2. 証明: LSKF 認証が成功したことを KeyMint(以前は Keymaster)に通知する HardwareAuthToken を発行します。

Weaver に移行する理由

Android 8.1 でセキュア パスコード リセット トークンが導入されたことで、合成パスワードが 主要な暗号シークレットになりました。上記の 2 つのロールは、別々の Gatekeeper 登録によって処理されます。1 つは LSKF 用、もう 1 つは合成パスワード用です。userId + 100000userId

Weaver は、最初のロールを引き継ぐために導入されました。よりシンプルな HAL インターフェースを使用し、セキュア エレメント(SE)ベースの実装をサポートしています。

機能 Weaver Gatekeeper
安全な削除 安全な削除が必要です。インターフェースは固定数の固定サイズのスロットを使用するため、 簡単に実装できます。 安全な削除は必須ではありません。インターフェースは無制限の登録をサポートしているため、実装は困難です。
ハードウェア SE 向けに最適化されていますが、TEE でも動作します。 事実上 TEE のみです。現在の設計では、SE に実装してもセキュリティ上のメリットはありません。
エラー処理 エラーコードが明確になります。 エラーコードが曖昧です。そのため、ロック画面では、誤った LSKF と無関係のエラーを区別できません。
アトミック性 Weaver を使用する LockSettingsService のコードは、 LSKF の変更をアトミックに実行します。新しいデータは新しい Weaver スロットに書き込まれ、 古いスロットは安全に削除できる場合にのみ消去されます。 Gatekeeper を使用する LockSettingsService のコードは、LSKF の変更をアトミックに実行しません。LSKF の変更中に問題が発生すると、 すべてのユーザーデータが失われる可能性があります。

参照コード

AOSP には、Weaver のリファレンス実装が 2 つ含まれています。

  • Android 17 以降では、 system/weaver/ に一般的なセキュア環境向けの Weaver 実装が含まれています。
  • Android 8.1 以降では、 external/libese/ に ISO/IEC7816-4 互換のセキュア エレメント向けの Weaver 実装が含まれています。

テスト

Weaver の実装を検証するには、 VtsHalWeaverTargetTest: を使用します。

atest VtsHalWeaverTargetTest

または

vts-tradefed run vts -m VtsHalWeaverTargetTest