| commit | e408190bfcce233520a432f59baa430d44bb853f | [log] [tgz] |
|---|---|---|
| author | jahinimtiaz <jahinimtiaz@google.com> | Tue Mar 14 00:15:35 2023 +0000 |
| committer | jahinimtiaz <jahinimtiaz@google.com> | Tue Mar 14 00:15:35 2023 +0000 |
| tree | afa6a314ebecc5e083a7d54389001f5fb111ffe6 | |
| parent | e603815ef243932be0ddcfb2d472451713a586c6 [diff] |
Include module dependencies under `data` Bug: 269138674 Test: Presubmit Change-Id: Ie3e677a53f7f646090fa934b2861811e89bdf8ee
RemoteProvisioner is the application responsible for driving the provisioning process for Remote Key Provisioning (RKP) between the device and server.
The application registers a periodic job using WorkManager. This job is scheduled to run once every ~24 hours in order to check the status of the attestation key pool and determine if further provisioning is needed. An active network connection is set as a prerequisite for the job to be executed.
RemoteProvisioner publishes an implementation of the IGenerateRkpKeyService. The Keystore frameworks code registers with this interface and notifies the application whenever the following conditions are met:
In the event of (1), the application will just check the key pool state in Keystore to determine if provisioning should be executed immediately, rather than waiting for the periodic provisioning check. In the event of (2), the binder call will block until the RemoteProvisioner can complete a provisioning step, allowing the original key generation request from the frameworks to seamlessly attempt generation again using one of the newly provisioned keys.
The RemoteProvisioner will also check the status of Widevine on device during boot. There are two relevant details to check before the application will take any further action related to Widevine:
(1) then check if the device is unprovisioned.If (1) and (2) are both true, the application will create a separate Widevine job which will trigger once network is made available in order to attempt to provision the stage 1 Widevine certificate before it's needed by other streaming services on device.
This exists as a convenience step, and should only ever run one time for a given device unless it is factory reset.
The device code is written such that a backing server implementation can set some variables on the application side, stored in SharedPreferences. These preferences are managed by SettingsManager. Server configurable variables include:
All or none of these variables may be present when the device receives them during a fetchEek request. Notably, the device also generates and sets an ID that it sends to the server during this fetchEek request, along with its build fingerprint. This allows the backend to configure different options for different device models if necessary, while supporting controlled rollout of new changes.
There are several test build targets defined within this repository. Each suite can be run by executing atest <<name>> from a terminal and Android checkout that is initialized with lunch.
These tests exercise and validate the expected functionality of the entire remote provisioning tech stack for the device. This suite includes full end-to-end tests which coordinate a provisioning step between the device and the backend server infrastructure.
This test verifies that the device has been registered with the backend server. It sends a CSR to the backend and waits to see if the server returns a response indicating that the device public key was not recognized - HTTP Error 444.
These tests validate behavior which requires host orchestration that would not be doable in RemoteProvisionerUnitTests. This is primarily related to validation of service behavior along with metrics collection.
These tests measure the round-trip performance in terms of time taken to send a certificate request and receive the certificates from the remote provisioning server.