The wifi stack will be running inside the network_stack process for
devices which will accept wifi mainline module in R. So, add a effective
uid entry to allow calls from wifi stack inside network_stack to use
keystore blobs stored by wifi uid.
Bug: 142298627
Test: Compiles, will verify failing tests.
Change-Id: Iff19bcad134a3531934215ea4b7d975433da787d
The operation device map needs to be cleand up on finish regardless of
whether the operations succeeds of fails. The operation lifecycle ends
in any case.
Bug: 141317862
Test: Generate key and perform repeated operations.
Watch memory consumptoin not raise with using:
adb shell dumpsys meminfo keystore
Change-Id: I3a25aa67f121832640848a38398c523e20a2c6df
A bug introduced in a patch intended to upgrade keystore master keys
to use AES-256 and SHA-256 instead of AES-128 and SHA1 causes the
newly-updated master key to fail to be retrievable ever again. Making
this worse, after five successive failures, keystore decided that all
the data is bad and wipes the user's keystore. This problem happens
on every password change if the master key is 128 bits. Luckily,
since the introduction of synthetic passwords to support escrow
tokens, the password presented to keystore is the synthetic password,
which never changes. So this problem only crops up in devices that
did not have synthetic passwords (launched with Android N or earlier),
were not upgraded to O DR1 (when synthetic passwords were enabled by
default), were never factory reset or had their password removed and
re-added during all of that time and were then upgraded to P or Q,
when the master key upgrade code was present.
This CL fixes the upgrade process so that updated master keys can be
used. It doesn't change the key size, the keys stay 128 bits, but now
they're readable and usable. Factory resetting allows an entirely
new master key to be generated, which will be AES-256.
Note that the keystore master key is not really essential to the
security of Keystore keys. They're also encrypted by the secure
world (TEE or SE), which is their primary protection. The master key
just provides a cryptographic dependency on the user's password, so
that in the event of a secure world break the attacker still has to
brute force the user's password to recover the key material, or use of
the protected keys.
Bug: 129970023
Test: Manual
Change-Id: I8ce2bb2359cf822039c137bb6bb1fc225da47c29
Test: still see keys loaded from /product appears in /proc/keys
Test: Add X.509 DER cert files to keystore, see the key in
/proc/keys after reboot
Bug: 112038744
Change-Id: I08006d8befa69e4bf416a2bed9e1813725877147
Replace libcrypto with libcrypto_static, which can be protected through
visibility to ensure only modules that don't affect FIPS certification
can use it.
Bug: 141248879
Test: m checkbuild
Change-Id: I4e0e287fab5d8968359dd98ad84b0a0713d93b41
As identified by Droidguard, a non-trivial percentage of attestations
fail with a missing attestation app ID. It's better to produce an
attestation with missing app ID than to fail, because not all
consumers of attestations care about the app ID.
Test: Keystore CTS tests.
Change-Id: I1a8d8a6873edab27771bff4ce9262f4fbe533e56
Test: can add a key from Settings/CertInstaller
Test: see the key loaded from an init script in /proc/keys
Bug: 112038744
Change-Id: I72b643d88ca4c0afce8a4e3bc64fef606daf8364
Since these were combined into libhidlbase.
Bug: 135686713
Test: build only (libhwbinder/libhidltransport are empty)
Change-Id: I940228446b6f5b747399b408ad9af652ac618fda
When operations are aborted by an app or an app dies, tokens are not
removed from the device token map. This patch moves the this map from
key_store_service to KeyStore so that it can be accessed by the
keymaster workers. It also adds calls to removeOperationDevice to the
binderDied hook of the keymaster workers as well as to keystore service
abort.
Add a call to removeOperationDevice() inside pruneOperation() function on
keystore/keymaster_worker.cpp
Bug: 139383076
Test: atest keystore_unit_tests (passed)
Change-Id: I90d4dc9d4510f4ac250022c89240a742b9e8d4b4
Keystore is originally a main service, but can be started earlier.
Making it a core service achieve our goal, while still keeps the
dependencies satisfied.
Specifically, the boot sequence in late-init looks like:
on late-init
...
trigger late-fs # starts early_hal class, e.g. keymaster-4-0
trigger post-fs-data # mounts /data
...
trigger boot # starts core class
Test: keystore still runs
Bug: 112038744
Change-Id: Ifd2192b927006b1c30d8e17be7c23e1459515d2c
In attestKey we did not check a return value after retrieving a key
blob. This results in a segfault if an attestation is requested on a non
existent or corrupted key.
Bug: 135907940
Merged-In: I1e84d334bb93ac878b63e15a59c35631f9e6e397
Change-Id: I1e84d334bb93ac878b63e15a59c35631f9e6e397
Keystore was conceptually single threaded. Even with the introduction of
Keymaster workers it was always assumed that the service dispatcher
thread was single threaded. The wifi keystore service, however, calls
into the keystore service concurrently.
This patch adds a lock around all keystore service entry points to make
sure all dispatcher executions are serialised despite being called from
both the binder and hwbinder service thread.
Bug: 128810613
Bug: 129145334
Bug: 128774635
Bug: 130045583
Bug: 131622568
Test: Regressions tested with Keystore CTS test suite.
Merged-In: I8c5602d2c2cb1dd9423df713037e99b247cee71f
Change-Id: I8c5602d2c2cb1dd9423df713037e99b247cee71f
(cherry picked from commit 4ea6d7a447)
