Status Update
Comments
jm...@google.com <jm...@google.com> #2
fk...@gmail.com <fk...@gmail.com> #3
Great! Thanks a lot, I'll look for the live updates soon!
jm...@google.com <jm...@google.com> #4
[Deleted User] <[Deleted User]> #5
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:
Best regards
[Deleted User] <[Deleted User]> #6
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> #7
is there any progress with that issue?
Regards
dr...@gmail.com <dr...@gmail.com> #8
When can we expect to see API 19+ support published?
Best
lc...@gmail.com <lc...@gmail.com> #9
ci...@gmail.com <ci...@gmail.com> #10
em...@gmail.com <em...@gmail.com> #11
[Deleted User] <[Deleted User]> #12
Hint.... we need 18 ;)
jm...@google.com <jm...@google.com> #13
th...@gmail.com <th...@gmail.com> #14
Many thanks.
ti...@gmail.com <ti...@gmail.com> #15
jm...@google.com <jm...@google.com> #16
lc...@gmail.com <lc...@gmail.com> #17
jm...@google.com <jm...@google.com> #18
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.
lc...@gmail.com <lc...@gmail.com> #19
dr...@codetri.be <dr...@codetri.be> #21
sa...@gmail.com <sa...@gmail.com> #22
jm...@google.com <jm...@google.com> #23
ch...@gmail.com <ch...@gmail.com> #24
[Deleted User] <[Deleted User]> #25
rg...@gmail.com <rg...@gmail.com> #26
bo...@google.com <bo...@google.com>
ap...@google.com <ap...@google.com> #27
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
ap...@google.com <ap...@google.com> #28
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
gm...@gmail.com <gm...@gmail.com> #29
Could you please explain why keystore is not used on API 21-22? There are
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> #30
tr...@gmail.com <tr...@gmail.com> #31
ka...@gmail.com <ka...@gmail.com> #32
ka...@gmail.com <ka...@gmail.com> #33
kr...@gmail.com <kr...@gmail.com> #34
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> #35
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> #36
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
Before Marshmallow (API 23), Android Keystore did not have support for symmetric keys. This, among
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 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
ka...@gmail.com <ka...@gmail.com> #37
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> #38
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> #39
bo...@google.com <bo...@google.com> #40
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> #41
bo...@google.com <bo...@google.com> #42
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
, those files are encrypted. The files are also protected by full-disk or file based encryption , 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 SELinux user permissions 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> #43
p....@anfe.ma <p....@anfe.ma> #44
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
>
da...@gmail.com <da...@gmail.com> #45
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>
jo...@gmail.com <jo...@gmail.com> #46
4b...@gmail.com <4b...@gmail.com> #47
Any news on this?
Description
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.