go/cleanup-greylist-txt
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: If694cc885291c0c0cf14d8b880fc7ac4948dbe1b
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
ag/5984229 that added support for AES-256 master keys inadvertently
caused them not to be encyrpted by the user's password. This is less
damaging to security than it might appear because these keys are also
encrypted by Keymaster, in the TEE or StrongBox.
Bug: 141955555
Test: Manually verify password is encryption on a userdebug build.
Change-Id: Ic5e82546df67346e4c348273cf4fe2bac382c9dc
(cherry picked from commit b951bc5317)
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
ag/5984229 that added support for AES-256 master keys inadvertently
caused them not to be encyrpted by the user's password. This is less
damaging to security than it might appear because these keys are also
encrypted by Keymaster, in the TEE or StrongBox.
Bug: 141955555
Test: Manually verify password is encryption on a userdebug build.
Change-Id: Ic5e82546df67346e4c348273cf4fe2bac382c9dc
Merged-In: Ie44a4097e058bd5b9e45aa73115c266b9570a4fc
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
