GitLab

* commit 'b570de56':
  Add ENGINE for BoringSSL.

This change adds a new ENGINE implementation for BoringSSL. It's a no-op
until external/openssl is switched to BoringSSL.

BoringSSL's ENGINEs are very different from OpenSSL's (and very much
smaller). Thus this change adds replacement code that is conditionally
compiled when BoringSSL is used.

Rather than building a .so that is put in a special directory and loaded
by OpenSSL dymanically, the code becomes a normal library that exports a
single function: EVP_PKEY_from_keystore. All the |ENGINE_load| etc
functions that callers previously needed become moot with BoringSSL.

Bug: 17409664
Change-Id: I8b5ba255f86ec5d0f28994358dc0f0b516f0af40

* commit 'd9adda97':
  Update softkeymaster for BoringSSL.

* commit '90c47791':
  Delete user's keys only after keystore reset

Original behaviour deletes all keys on the device, not just those for
the caller. We use the clear_uid routine to call delete_keypair on all
known keys instead.

Bug: 17403144
Change-Id: If43465ed593153a557b2129968a3adf12d2749cb

* commit 'a39da5a2':
  Fallback to software keystore on import_key failure

This is to allow keymaster HAL 0.3 types to be able to fallback when
they don't support DSA or EC keys.

Bug: 17576126
Change-Id: I7e1e806e26fb61e2cd033d7d3a2c09560764ca42

* Disable an odd, 192-bit curve that BoringSSL no longer supports.
* Only set the "ASN.1 flag" when not using BoringSSL as it's the default
  now in BoringSSL.
* Use a non-deprecated function to free the thread's error queue.

Change-Id: I54a08724aef0344421fe9097e524d66550af0f81

* commit '31e27468':
  isEmpty checks all files like reset

Since reset deletes all files in a user directory, change isEmpty to
alse look at all files in the directory. This makes the two symmetric.

Bug: 16935053
Change-Id: Id30685203f4b5484d757022ee971f8d877c15263

* commit 'f583a75c':
  Comment out unused parameter.

BUG: 17281763
Change-Id: I1881e31893cd2d84389e4b29a4408d58654c20ca

* commit 'b4918b9a':
  Build keystore in 32 bit on platforms that require it.

* commit '4e865753':
  APIs for syncing password between profiles

Change-Id: I29543f72ef677870aa3f108c1ae4cb029df2f871

* commit '4a16cd72':
  Build keystore in 32 bit on platforms that require it.

Change-Id: I29543f72ef677870aa3f108c1ae4cb029df2f871

Bug: 16233206.
Change-Id: I7941707ca66ac25bd122fd22e5e0f639e7af697e

* commit '05e449a0':
  Correct double-convert from uid to userid

* commit '50122db5':
  Correct double-convert from uid to userid

This was making readMasterKey and writeMasterKey always operate on
user 0, because of a double-division - getUserState(*) already
takes into account that the argument is a uid.

Fixes a number of issues related to multi-user and keystore; works
toward fixing bug 16233206.

(cherry picked from commit 50122db5)

Change-Id: Ia1434fd0d076b0c36d383ff7390b17c78d7811b5

This was making readMasterKey and writeMasterKey always operate on
user 0, because of a double-division - getUserState(*) already
takes into account that the argument is a uid.

Fixes a number of issues related to multi-user and keystore; works
toward fixing bug 16233206.

Change-Id: Ia1434fd0d076b0c36d383ff7390b17c78d7811b5

* commit 'a6247469':
  keystore: allow system to clear keys even while encrypted

* commit '931fac09':
  keystore: fully reset user keystore on request

* commit 'cf5a7fc9':
  keystore: fully reset user keystore on request

The reset was improperly skipping the .masterkey file which left
keystore in a "LOCKED" state next time it was started up. The .masterkey
should have been deleted to leave it in the requested "UNINITIALIZED"
state next time it started.

It looks like some logic was left over to check the UID to see if it
matches the current user. Currently there's no way to have a UID in
the user directory that doesn't match the current user.

(cherry picked from commit a71c9d6b)

Bug: 13886753
Change-Id: Icd3a1a55153a0dd28a26d51a5ae7f6de1a7da043

* commit 'd5d811e4':
  keystore: allow system to clear keys even while encrypted

Since we can store keys that are unencrypted, we should allow the
clearing of data for apps when the keystore is still in a LOCKED state.
Also allow the system user to delete keys since this is necessary for
system maintenance when application data is cleared or the application
is uninstalled.

Bug: 15751553
Change-Id: Id02bc9992bd529e79be7a09d2bce208942d42b84

Since we can store keys that are unencrypted, we should allow the
clearing of data for apps when the keystore is still in a LOCKED state.
Also allow the system user to delete keys since this is necessary for
system maintenance when application data is cleared or the application
is uninstalled.

(cherry picked from commit e17c2545)

Bug: 15751553
Change-Id: Id02bc9992bd529e79be7a09d2bce208942d42b84

The reset was improperly skipping the .masterkey file which left
keystore in a "LOCKED" state next time it was started up. The .masterkey
should have been deleted to leave it in the requested "UNINITIALIZED"
state next time it started.

It looks like some logic was left over to check the UID to see if it
matches the current user. Currently there's no way to have a UID in
the user directory that doesn't match the current user.

Bug: 13886753
Change-Id: Icd3a1a55153a0dd28a26d51a5ae7f6de1a7da043

* commit '00b27fc4':
  Add calls for SELinux MAC checks in keystore.