cioccarellia/ksprefs

Add support for AndroidKeyStore key storage

Closed this issue ยท 21 comments

In your README, you've suggested using cipher.so, but we could also use the AndroidKeyStore to:

  • Store the symmetric key for API >= 23
  • Store an asymmetric keypair to wrap a symmetric key for 18 < API < 23

I'd be happy to submit a pull request for it. This would allow users of this library to get a much enhanced layer of security for free!

Well, I'd like to be humble, I've heard about it but I've never scratched the surface of the iceberg, what would the new implementation look like?
It is interesting, if we could work together it would be great

I found this material and these details, it seems such a nice idea, I'm surely going to add it to the library as soon as I have free time.

I loosely followed a guide by Yakiv Mospan https://proandroiddev.com/secure-data-in-android-encryption-7eda33e68f58, and got a solid implementation working. I managed to take an existing SharedPreferences object and wrap it to be fully encrypted.

I'd be happy to work on it together!

Feel free to open a pull request for this. I've just pushed an update (1.3.1.0) to address every problem we have encountered so far, thus the library is ready to be modified.

I'll create a separate branch for this (android-keystore)

Hey! Any updates on this?

Hi! I was busy with personal stuff last week. Will get started on this module this week!

Hi Andrea,

Things have settled down and I have had a chance to look at this repo a little more closely.

API Support

First thing to address is that the Android Keystore can only be used in API versions 18+
I'm not sure if there are options for different constructors/library modules for different API versions.
We could also discuss having a Builder for Cryptoprefs to support multiple configurations

Key storage for APIs 18-22

Next up, the way Symmetric keystore encryption works in in APIs 18-22 is:

  • Generate an asymmetric keypair from the Keystore (RSA)
  • Generate your own symmetric key (AES)
  • Encrypt the AES key with the RSA Public key, and store it on the device
  • When encrypting or decrypting with the AES key: load the encrypted AES key from storage => decrypt with the RSA private key => use decrypted AES key
    We should decide if we want to create a new preferences file for storing this key or store it in the default shared preferences.
    This also brings with it issues with storage space, so we may have to include the READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE manifest options

I think that that's a very good base but maybe we could do that on another project, because dropping compatibility for old android versions, requiring additional permissions and migration techniques wouldn't be the best thing for this library.
Once some time has passed we can overcome those issues but for now I'd close this issue, hoping one day to open it again :)

Sadly there was no progress on the topic. Although it is a well written and documented project, but from a security perspective the library can't be considered as a security mitigation without the keystore support, especially with the latest progress of keystore hardware support. BTW, there is no need to use asymmetric encryption for API 23+ (Android 6+). The builder should generate a keystore based AES key (hardware protected) and then use it in order to encrypt pref file elements instead of current approach when it is being passed by the host app. RSA alg, as presented by Arsala, can be used for backward compatibility for Android 4.3-5.* versions.

Hey!
I've actually been really busy in those last months.
I wanted to re-write this library from scratch in a 2.0 version, and take advantage of the latest AndroidX security components, while achieving better Kotlin compatibility, along with some other sweet things.
Think is, and I'm gonna say that with all my humbleness, I don't know a thing about encryption.
I want to get some background, to study this field and to build a library everybody can use and trust.
Hoping to work with you in the future.
Check this out in a few months, you may like what you'll see :)
And many thanks for supporting my work.

Talking to both of you, @ArsalaBangash and @6d69636861656c ๐Ÿ˜Œ

Great to here about the plans! Actually there is a heavy demand among corporate customers for such a library which supports hw security module out of the box. I'll try finding time to write a code which will support the the most secure standards for each device/Android version mix and will have granual config support. Hopefully when it will be done you can either include it as an optional wrapper class which protects the encryption key (still not the most secure thing, since the key would be available to the app in run-time) or incorporate it into the latest 2.0 release, so the library will will use a securevault based crypto api in order to encrypt/decrypt the the config areas.

Sadly, security is a really delicate and hard topic for developers facing it for the first time.
I believe it should be much funnier and nicer to pick up.

I originally just picked up code here & there and merged it together in a library.
I'm learning lots of new things and I see this library not having tests, logging operations, asynchronous support, CI, and a full bunch of other stuff.
The release I'm aiming at is going to be a complete rewrite, which will take advantage of a bunch of Hardware/Software features to bring security at a better level.

Specifically, I'm planning to bundle in:

A constant factor in encryption libraries is that if your app can access and edit your preferences, so can a root user with enough knowledge.
This is why I can not bundle a complete security system out of the box, but I have to leave it open so that the user can integrate this library tightly with the target software.

As I'll have finished my current pending project, this will be the next thing I'll get down to :)

Clearly this won't be backward-compatible with any previous version. But I think It'll be worth the effort.

Sounds very promising!

Hey Andrea,
I resonate with the feeling that security and cryptography is not the gentlest topic to pick up, but it's great to see that a re-write is taking place here.

It's lovely to see that there's now a Jetpack library for cryptography. When this didn't exist, a combination of your library's skeleton and Yakiv Mospan's Medium Articles helped me when developing a secure storage solution for my company's Android app.

I agree Michael that "there is a heavy demand among corporate customers for such a library which supports hw security module out of the box."

I wish you all the best with this library and I would encourage you to look for financial backing for the great work you do through options like Open Collective

Rewrite's taking place :)

I've built a really nice base library. KsPref 2.0.0 is under heavy testing.

Right now the implementation looks like this: for K-M devices we use android keystore to store a keypair, wlist on M+ devices we use the keystore to perform the operations.

I'll close the issue as the base idea was completed and implemented. Though, there is more to come :)