| commit | f44b8627af4a515a8cfd41862f0b93eb49bb4c89 | [log] [tgz] |
|---|---|---|
| author | David Drysdale <drysdale@google.com> | Wed Jan 17 15:43:20 2024 +0000 |
| committer | Gerrit Code Review <noreply-gerritcodereview@google.com> | Wed Jan 17 15:43:20 2024 +0000 |
| tree | d4acd40f5a9eb66fbcfa735b88dda1b3875028a5 | |
| parent | 2464aee4f245581b476d6be09a47f5f74a07fce1 [diff] | |
| parent | 8ac8eb834b59d550e620f8bb45026820cce8351f [diff] |
Merge "Improve readability" into main
Secretkeeper provides secure storage of secrets on behalf of other components in Android. It is specified as a HAL and must be implemented in an environment with privilege higher than any of its clients. Typically this will be a trusted execution environment such as ARM TrustZone.
The core SecretManagement API is a CBOR based protocol and can be used to store (& get) 32 bytes of secret data. Secretkeeper supports establishing secure channel with clients as well as deletion of some or all data.
The requests (from client) & responses (from Secretkeeper) must be encrypted using symmetric keys agreed between the client & service. For this, Secretkeeper (& client) must implement the AuthGraph key exchange protocol to establish a secure channel between them.
In the key exchange protocol, the client acts as P1 (source) and Secretkeeper as P2 (sink). The interface returned by getAuthGraphKe() can be used to invoke methods on the sink.
The storage layer of Secretkeeper, in addition to conventional storage, provides DICE policy based access control. A client can restrict the access to its stored entry.
The underlying storage of Secretkeeper should offer the following security guarantees:
Secretkeeper uses DICE policy based access control. Each secret is associated with a sealing policy, which is a DICE policy. This is a required input while storing a secret. Further access to this secret is restricted to clients whose DICE chain adheres to the corresponding sealing policy.
Microdroid instances use Secretkeeper to store their secrets while protecting against the Rollback attacks on the boot images & packages. Such secrets (and data protected by the secrets) are accessible on updates but not on downgrades of boot images and apks.