2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
Remote Key Provisioning
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
リモートキーのプロビジョニング(RKP)は、Android 12 以降、AOSP の一部です。Android 14 では、リモート プロビジョニングの更新可能なモジュールが導入され、サービス API の堅牢性を高めてサービス API の改善に要する時間を短縮することで、機能の復元性を高めています。
目的
すべてを APEX にパッケージ化することで、RKP サービスを簡素化します。
Android 14 より前では、RKP はアプリ RemoteProvisioner
とキーストア 2.0 に分離されていました。RemoteProvisioner
アプリが RKP バックエンドと通信し、Keystore 2.0 が鍵の保存と HAL との通信の両方を実施していました。RKP 鍵とキーストアの鍵は添付されるメタデータの点で大きく異なるため、これは良好なアーキテクチャではありません。さらに、RemoteProvisioner
がリソース不足の可能性を警告するように、キーストア フレームワークのコードを不自然な形で変更する必要がありました。
Mainline モジュールとしての RKP は、これらの点を改善するように設計されており、すべてを APEX にうまく組み込むことができます。
モジュールの境界
RKP Mainline APEX(com.android.rkpd
)には、Remote Key Provisioning Daemon(RKPD)アプリケーションと、リモート プロビジョニング システム サーバー コンポーネント(Java でビルド)が含まれています。
スタック アーキテクチャ
図 1 は、RKP スタックのアーキテクチャを示しています。
図 1. RKP スタックのアーキテクチャ。
内部アーキテクチャ
図 2 は、RKP 内部アーキテクチャを示しています。
図 2. RKP 内部アーキテクチャ。
RKP 内部アーキテクチャに関する追加情報:
このモジュールのアプリケーションやその他の機能は、APEX ファイル com.android.rkpd
としてパッケージ化されます。
依存関係
RKP モジュールは引き続き、証明書鍵と証明書リクエストの提供で IRemotelyProvisionedComponent
実装の存在に依存します。
テスト戦略
アプリ APEX の AOSP バージョンには、OEM が実行できる単体テストが含まれています。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-10 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-10 UTC。"],[],[],null,["# Remote Key Provisioning (RKP) has been a part of AOSP since Android\n12. Android 14 introduces a\nremote provisioning updatable module that increases feature resilience by\nimproving the robustness of the service API and decreasing the time to\nintroduce any improvements to it.\n\nMotivation\n----------\n\nSimplify the RKP service by packaging everything into an APEX.\n\nBefore Android 14, RKP was separated into an app,\n`RemoteProvisioner`, and Keystore 2.0. The `RemoteProvisioner` app was\nresponsible for contacting the RKP backend, and Keystore 2.0 was responsible for\nboth storing the keys and communicating with HALs. This wasn't a good\narchitecture because RKP keys are significantly different from Keystore keys in\nterms of attached metadata. Additionally, this required awkward modifications to\nthe Keystore framework code to alert `RemoteProvisioner` about potential\nresource starvation.\n\nRKP as a Mainline module is designed to improve on these points by neatly\npacking everything into an APEX.\n\nModule boundary\n---------------\n\nThe RKP Mainline APEX, `com.android.rkpd`, contains the Remote Key Provisioning\nDaemon (RKPD) application and a remote provisioning system server component\n(built with Java).\n\n### Stack architecture\n\nFigure 1 illustrates the RKP stack architecture.\n\n**Figure 1.** RKP stack architecture.\n\n### Internal architecture\n\nFigure 2 illustrates the RKP internal architecture.\n\n**Figure 2.** RKP internal architecture.\n\nAdditional information about the RKP internal architecture:\n\n- RKPD Mainline APEX - `com.android.rkpd`\n\n - RKPD app (Java)\n - `packages/modules/RemoteKeyProvisioning/app`\n - RKPD system server fragment (Java)\n - `packages/modules/RemoteKeyProvisioning/system-server`\n- HAL interface/implementation (Rust/C++)\n\n - `IRemotelyProvisionedComponent`\n - `hardware/interfaces/security/keymint`\n\nPackage format\n--------------\n\nThe application and other functionalities of the module are packaged as APEX\nfile `com.android.rkpd`.\n\nDependencies\n------------\n\nThe RKP module continues to depend on the existence of\n`IRemotelyProvisionedComponent` implementations to provide the attestation keys\nand certificate requests.\n\nTesting strategy\n----------------\n\nThe AOSP version of the application APEX contains unit tests that OEMs can run."]]