A proper fix for this feature requires reworking binder permission
checking to take the selinux context and not the pid. This is feature
work that should be done for P to properly fix these race conditions
that occur elsewhere in the code.
Bug: 68217699
Test: KeyStore keygen permissions cannot be bypassed through PID cycling
Change-Id: I1ba5210010d6c413c9b1dbde3df0cc566400bfac
This patch also adds test for the functions hidlVec2AuthToken
and authToken2HidlVec.
Test: /data/nativetest64/keystore_unit_tests/keystore_unit_tests
Change-Id: I823939a62ca94efa45509c89d1013ec87f51d04c
auth_token_table tests did not make the transition to hidle types and
were broken.
Noww they use the hidle types as well.
Also this patch fixes an awkward ownership transfer of an object
referred to by a const pointer and reduses the use of the type hw_auth_token.
Test: Ran all keystore CTS test as well as the fixed auth_token_table
tests
Bug: 68149839
Change-Id: Ia69a80fad12edc134646a7b340f8e27ea4da2210
Generated IKeystoreService has different signature, which required lots
of refactoring.
After update methods relevant data using last parameter.
Test: cts-tradefed run cts -m CtsKeystoreTestCases
Bug: 68389643
Change-Id: I0ca36a2e9e007143a3b403b306a8f979ee98b232
This is ancient code that isn't used. In addition, it's a keymaster0
implementation, and we're removing support for keymaster0.
Test: N/A
Change-Id: I4b473af04d77ccb4c9aa64a964a855ef0977c570
Test: I solemnly swear I tested this conflict resolution.
Change-Id: Ie605cbb7f90eca6d17c2c5f6a50ec1ee21edf633
Merged-In: I6709b7562d47ad6156bee88a9e2d961f8a4a797d
Fix issues in keystore where it didn't handle key upgrade for granted keys
or keys with effective uid (keys under WiFi uid) correctly.
Test: manual
Bug: 66094261
Change-Id: I6709b7562d47ad6156bee88a9e2d961f8a4a797d
Merged-In: I6709b7562d47ad6156bee88a9e2d961f8a4a797d
Fix issues in keystore where it didn't handle key upgrade for granted keys
or keys with effective uid (keys under WiFi uid) correctly.
Test: manual
Bug: 66094261
Change-Id: I6709b7562d47ad6156bee88a9e2d961f8a4a797d
Merged-In: I6709b7562d47ad6156bee88a9e2d961f8a4a797d
Fix issues in keystore where it didn't handle key upgrade for granted keys
or keys with effective uid (keys under WiFi uid) correctly.
Test: manual
Bug: 66094261
Change-Id: I6709b7562d47ad6156bee88a9e2d961f8a4a797d
Merged-In: I6709b7562d47ad6156bee88a9e2d961f8a4a797d
We observed on some Pixel C that they sometimes generate auth token with
a stuck timestamp value. Since the timestamp value does not increase,
newer auth token is not considered "superceding" old auth tokens and keystore
end up retrieving older auth tokens which are then treated as expired due to
its time_received value being too old.
We workaround this issue by comparing both the timestamp (which is part of
auth token) and the time_received (which is a monotonic clock value at the
time auth token is sent to keystore). So a new auth token with stuck timestamp
value but newer time_received still supercedes older auth tokens.
This is actually sufficient to workaround the issue on Pixel C, since the stuck
timestamp value is returned by the secure RTC, whose value is also used by
keymaster TA to check key authorization. In other words, the auth token is
still good to authorize auth-bound keys, even with a stuck timestamp value.
This does mean that on the affected Pixel C, auth-bound keys are not enforced
at TrustZone leve, but merely a logical check in keystore daemon.
Bug: 65283496
Test: boot device, unlock successfully
Change-Id: I0b9d5463e94241bfaf552dcb31fea04ee966596c
