API level support [132325342]

Bug

Status Update

No update yet.

Description

lc...@gmail.com

created issue #1

May 9, 2019 04:25PM

Attended the talk at Google Io 19. Great information.

And saw that the minsdk support for jetpack security library is Android 6+(API 23+). Would it be possible to support from Android 4.4.x(API 19+) as currently for my project (a govt national identity application), we need to support 95% of the devices out there.

Comments

jm...@google.com <jm...@google.com> #2May 21, 2019 09:45AM

Hi Ed, Thank you so much for these suggestions. I've been reviewing them and merging them in. Hopefully it should be live. I've included a thank you note too in the article.

fk...@gmail.com <fk...@gmail.com> #3Jun 5, 2019 07:07AM

Great! Thanks a lot, I'll look for the live updates soon!

jm...@google.com <jm...@google.com> #4Jun 21, 2019 12:54AM

This is in the works and currently in security review. You can follow along here -

https://android-review.googlesource.com/c/platform/frameworks/support/+/985248

[Deleted User] <[Deleted User]> #5Jul 31, 2019 09:23PM

Hi,
Thank you for the great work! I'm also really eager to see this released!

I just reviewed the changes and I have a few observations:

1) Why use CHACHA20_POLY1305 if API < 23? From what I understand the encryption is handled by Tink so there is no minimum API to use AES-GCM-256 as Aead.

2) It looks like the modification does not handle the case where a device is updated from >= 19 and < 23 to >= 23: The encrypted data will be lost. As here:

https://github.com/google/tink/blob/09fc71c45dc7c4ecc7fb0df3414b0fb3a9ca52c3/java/src/main/java/com/google/crypto/tink/integration/android/AndroidKeysetManager.java#L313 I think the case where the device is updated should be handled.

Best regards

[Deleted User] <[Deleted User]> #6Jul 31, 2019 10:18PM

And one more:

3) Why set the minimum version to 19 when it can be used on 18? I have successfully built EncryptedSharedPreference with Android 18 support, simply by changing the minSdfk field.

pi...@gmail.com <pi...@gmail.com> #7Aug 21, 2019 04:11PM

Hi,
is there any progress with that issue?

Regards

dr...@gmail.com <dr...@gmail.com> #8Aug 27, 2019 04:51PM

Hi all,

When can we expect to see API 19+ support published?

Best

lc...@gmail.com <lc...@gmail.com> #9Sep 25, 2019 10:21AM

any updates on this issue?

ci...@gmail.com <ci...@gmail.com> #10Sep 27, 2019 03:47PM

Any updates?

em...@gmail.com <em...@gmail.com> #11Oct 14, 2019 08:55PM

We are looking to use this library for 21+, are there any updates? I don't see where I can follow along in the sec review it looks like nothing has been commented on since June?

[Deleted User] <[Deleted User]> #12Oct 15, 2019 03:03PM

+1 for why stop at 19? Go as low as you can go whilst providing an alternate form of encryption if Tink cannot.

Hint.... we need 18 ;)

jm...@google.com <jm...@google.com> #13Nov 20, 2019 11:24PM

Accepted by jm...@google.com.

API Level 19 and up will be in the next release of Jetpack Security. Thank you all for the feedback and patience. We're scheduling the release now, and I will update this when we have a concrete date.

th...@gmail.com <th...@gmail.com> #14Dec 19, 2019 01:50PM

Apologies for another bump, is there a schedule for the next release? Would make for a nice Christmas present!

Many thanks.

ti...@gmail.com <ti...@gmail.com> #15Jan 8, 2020 10:12AM

Hi any updates about release 19+

jm...@google.com <jm...@google.com> #16Jan 14, 2020 08:33PM

We're still working on this. Apologies for the delay, I cannot provide an ETA unfortunately.

lc...@gmail.com <lc...@gmail.com> #17Jan 27, 2020 01:12PM

bump for updates. my project is waiting for this change. seems to be stalled since Janurary 16th

https://android-review.googlesource.com/c/platform/frameworks/support/+/1182622

jm...@google.com <jm...@google.com> #18Jan 27, 2020 11:44PM

Sorry you're blocked on this.

We're working through some decisions on our side. The implementation for pre-Marshmallow versions of Android will not use the AndroidKeyStore as per Tink's documentation.

https://github.com/google/tink/blob/master/docs/KNOWN-ISSUES.md#android

lc...@gmail.com <lc...@gmail.com> #19Mar 11, 2020 11:19AM

is there any updates on this?

lc...@gmail.com <lc...@gmail.com> #20Mar 20, 2020 05:04PM

is this abandoned?

https://android-review.googlesource.com/c/platform/frameworks/support/+/1182622

dr...@codetri.be <dr...@codetri.be> #21Mar 20, 2020 07:08PM

Why is this feature abandoned?

sa...@gmail.com <sa...@gmail.com> #22Mar 20, 2020 07:32PM

+1 why abandoned?

jm...@google.com <jm...@google.com> #23Mar 20, 2020 07:43PM

That specific CL was abandoned, we are still looking into how to add this to the API. It's a feature we are very much still interested in building. Thank you for your patience, we are doing all we can to get this added. This is still an open feature request for us.

ch...@gmail.com <ch...@gmail.com> #24Apr 15, 2020 02:53PM

Sorry to bother, but Is there an ETA available yet?

[Deleted User] <[Deleted User]> #25Apr 20, 2020 05:56PM

This would be extremely helpful for an app that my team is developing that has a minimum API version of 16.

rg...@gmail.com <rg...@gmail.com> #26Apr 30, 2020 11:30AM

Keen to use this library but I a still waiting for 21+ support.

bo...@google.com <bo...@google.com> May 6, 2020 10:29PM

Reassigned to bo...@google.com.

ap...@google.com <ap...@google.com> #27May 21, 2020 11:10PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit 5dc65a7882dabeb8ea4c3bebb5e7d95aa113616a
Author: Nicole Borrelli <borrelli@google.com>
Date: Wed May 06 15:26:34 2020

Updates to support minSdkVersion=21

This creates a new "MasterKey" class that holds onto a key alias even
when that key may not exist in Android keystore.

Methods in EncryptedFile and EncryptedSharedPreferences also accept a
new MasterKey instance, in addition to the String "masterKeyAlias".

Relnote: "Add support for Android Lollipop (API 21+) via a new MasterKey
class. Because the Android keystore is not used prior to Android M (API
23+), developers should be aware that the keystore will _not_ be used
on Android L (API 21 and 22)."

Test: Existing and new tests pass
Bug: 132325342
Change-Id: I7c12d205273e4b652271865e53ff6c406632f407

M security/crypto/api/1.1.0-alpha01.txt
M security/crypto/api/current.txt
M security/crypto/api/public_plus_experimental_1.1.0-alpha01.txt
M security/crypto/api/public_plus_experimental_current.txt
M security/crypto/api/restricted_1.1.0-alpha01.txt
M security/crypto/api/restricted_current.txt
M security/crypto/build.gradle
M security/crypto/src/androidTest/java/androidx/security/crypto/EncryptedFileTest.java
M security/crypto/src/androidTest/java/androidx/security/crypto/EncryptedSharedPreferencesTest.java
A security/crypto/src/androidTest/java/androidx/security/crypto/MasterKeySecureTest.java
A security/crypto/src/androidTest/java/androidx/security/crypto/MasterKeyTest.java
M security/crypto/src/androidTest/java/androidx/security/crypto/MasterKeysTest.java
M security/crypto/src/main/java/androidx/security/crypto/EncryptedFile.java
M security/crypto/src/main/java/androidx/security/crypto/EncryptedSharedPreferences.java
A security/crypto/src/main/java/androidx/security/crypto/MasterKey.java
M security/crypto/src/main/java/androidx/security/crypto/MasterKeys.java

https://android-review.googlesource.com/1304915

ap...@google.com <ap...@google.com> #28May 27, 2020 03:16PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit ad607178d97045fb1de089a875fd0ff4b80dece3
Author: Nicole Borrelli <borrelli@google.com>
Date: Tue May 26 22:09:26 2020

Pin androidx.collections version

Pin a specific version of androidx.collections for the library.

Bug: 132325342
Test: Existing tests pass
Change-Id: Id01320c4d42d739085eda365fefcdb1b6681d116

M security/crypto/build.gradle

https://android-review.googlesource.com/1317940

gm...@gmail.com <gm...@gmail.com> #29Jun 17, 2020 12:41PM

Could you please explain why keystore is not used on API 21-22? There are ways to workaround its limitations.

Does it mean keysets are stored in cleartext on these devices? If yes, how can it be called "security"?

tr...@gmail.com <tr...@gmail.com> #30Jun 26, 2020 06:56AM

#29 - we use SecurePreferences and they support API 21-22 keystore, however it is not available for every phone, some phones do not give up private keys stored in keystore. There is a minority of such devices, but they do exist.

tr...@gmail.com <tr...@gmail.com> #31Jun 26, 2020 06:58AM

But yeah, question is legit - are they keys for API 21-22 stored in cleartext? I mean why then support these APIs if it's true as it may lead to major security issues as not everybody go in depth through the library details :/

ka...@gmail.com <ka...@gmail.com> #32Jul 23, 2020 08:26PM

Isnt this a major security flaw? Why not use asymmetric encryption to wrap master key on 21-22. And "Android Key Store" is available on 21-22 via KeyPairGeneratorSpec? What does google expect developers to do on API 21 and 22 for security?

ka...@gmail.com <ka...@gmail.com> #33Jul 23, 2020 09:10PM

To get this approved for our company, i have to specify in what way EncryptedSharedPref secures the master key on 21-22. Some official documentation would be very helpful

kr...@gmail.com <kr...@gmail.com> #34Jul 24, 2020 01:17PM

My understanding of the change is that the secure prefs key is stored in cleartext for API < 23. This is of course a huge issue, and is actually worse than not supporting API < 23 at all, because developers may believe they have implemented secure encryption of this data when in fact they have not. It's false security. I am also a bit confused as to why an asymmetric keypair was not chosen for API < 23.

ou...@gmail.com <ou...@gmail.com> #35Jul 27, 2020 03:04PM

I've read some codes in Tink.
Under Android M, security library uses Tink's AesGcmJce.encrypt() to encrypt the preference values.
So, actually, the values are not stored as clear text but encrypted text.
But it can't use KeyStore so IV's attached to value and encrypted key's bytes array is used as AAD.
As a result, yes, it's insecure.
Please let me know if I'm wrong.

bo...@google.com <bo...@google.com> #36Jul 27, 2020 09:08PM

Before getting into details, the TL;DR is this: in order to improve your app’s security, it should only be allowed to run on devices that receive regular security updates¹.

Before Marshmallow (API 23), Android Keystore did not have support for symmetric keys. This, among other reasons, is why we don't use the Keystore on those versions. Although workarounds exist, the larger concern is that these devices are no longer receiving security updates.

Without security updates, an actor can utilize exploits to gain access to encrypted data, _even when those secrets are protected by a TEE_².

Using the Jetpack security library makes it more difficult for an actor to access those secrets. Tink stores keys in the app's shared preferences, which are saved in the app's private directory. On devices which use full-disk or file based encryption, those files are encrypted. The files are also protected by SELinux user permissions, so that other apps, including the user when connected via ADB or USB, cannot access them. So an app or user cannot simply dump or fopen the keys.

We felt that the functionality provided by the library would be helpful for developers, including developers who, for various reasons we understand, need to support users on devices that run older versions of Android. ¹ It's possible to verify the OS version and patch level with key attestation of the Android Keystore. ² Even if the TEE itself is secure, if an app has root access it can simply ask the TEE to decrypt the data it would like access to.

ka...@gmail.com <ka...@gmail.com> #37Jul 29, 2020 04:46PM

Tink stores keys in the app's shared preferences, which are saved in the app's private directory.

This is true. But if you consider this a secure directory, why bother having an EncryptedSharedPreferences.java?

bo...@google.com <bo...@google.com> #38Jul 29, 2020 07:54PM

Tink stores keys in the app's shared preferences, which are saved in the app's private directory.

This is true. But if you consider this a secure directory, why bother having an EncryptedSharedPreferences.java?

Saving information into an app's private directory is safe. EncryptedSharedPreferences is intended to store small bits of data that are particularly sensitive. By using it, it increases the amount of effort required to extract that data from the device.

ss...@gmail.com <ss...@gmail.com> #39Jul 31, 2020 01:53PM

How secure is storing keys in Shared Preferences? Wouldn't a rooted user be able to lift the keys (even if they are encrypted)?

bo...@google.com <bo...@google.com> #40Jul 31, 2020 05:55PM

How secure is storing keys in Shared Preferences? Wouldn't a rooted user be able to lift the keys (even if they are encrypted)?

A rooted user can always access an app's data. It's more difficult when it's encrypted, and it's even more difficult when the key is stored in Key Store, but it's always possible for a rooted user to gain access to data on their device.

ss...@gmail.com <ss...@gmail.com> #41Jul 31, 2020 06:36PM

That doesn't really answer my question as to how secure Android's saving of keys to Shared Preferences is.

bo...@google.com <bo...@google.com> #42Jul 31, 2020 06:49PM

That doesn't really answer my question as to how secure Android's saving of keys to Shared Preferences is.

From reply #36:

Tink stores keys in the app's shared preferences, which are saved in the app's private directory. On devices which use full-disk or file based encryption, those files are encrypted. The files are also protected by SELinux user permissions, so that other apps, including the user when connected via ADB or USB, cannot access them. So an app or user cannot simply dump or fopen the keys.

Files stored in an app's private directory, which includes regular SharedPreferences files, are generally secure.

ss...@gmail.com <ss...@gmail.com> #43Aug 3, 2020 03:34PM

Thank you for the information.

p....@anfe.ma <p....@anfe.ma> #44Oct 15, 2020 10:05AM

So, although SharedPreferences / the app sandbox are generally considered secure it is good practice to additionally encrypt sensitive information - hence the existence of EncryptedSharedPreferences.
Woudn't it be logical to support encryption for Android 21 & 22 utilizing asymmetric keys?

Like suggested here:
> There are known workarounds which allow generation of symmetric keys backed by Android Keystore on API < 23 by generating symmetric keys using different provider (Bouncy Castle), encrypting them with private key from asymmetric keypair stored in Android Keystore (assymetric keys are supported by Android Keystore from API >= 19) and storing them in internal storage. Such workarounds should be implemented in
>

https://github.com/google/tink but I didn't find similar public issue there. Maybe it should be started?

da...@gmail.com <da...@gmail.com> #45Nov 25, 2020 10:57AM

Hi, does the library support migration from Android 21 (Lollipop) and Android 23 (Marshmallow)?

In other words, if I ship an app using androidx.security 1.1.0-alpha01 / 1.1.0-alpha02 on a lollipop device, what will happen when (if) the device is updated to android 23?

Will the data be migrated to the usage of the masterkey?

thanks!

bo...@google.com <bo...@google.com> Jul 28, 2021 01:04PM

Reassigned to jm...@google.com.

jo...@gmail.com <jo...@gmail.com> #46Oct 4, 2021 03:31PM

Any updates on this? The alpha03 was published some months ago, and it looks like there's been updates to the source repo as of a couple months ago:

https://github.com/androidx/androidx/tree/androidx-main/security/security-crypto/src/main/java/androidx/security/crypto

When will 1.1.0 be stable?

4b...@gmail.com <4b...@gmail.com> #47Dec 16, 2021 09:34PM

Any news on this?

st...@gmail.com <st...@gmail.com> #48Mar 5, 2022 05:59PM

Also hoping for news on this...

jm...@google.com <jm...@google.com> Mar 8, 2022 09:10PM

Status: New

st...@gmail.com <st...@gmail.com> #49Jan 30, 2023 10:25AM

Good morning from 2023 :) Any news on this...?