KeyNotValidYetException OnePlus3T Timezones

[StuStirling]

Hi,

I'm not sure if it's specific to the OnePlus3T or its more of a timezone issue but when trying to create a new AES key on this device I get the following exception:

 android.security.keystore.KeyNotYetValidException: Key not yet valid
W:     at android.security.KeyStore.getInvalidKeyException(KeyStore.java:684)
W:     at android.security.KeyStore.getInvalidKeyException(KeyStore.java:748)
W:     at android.security.keystore.KeyStoreCryptoOperationUtils.getInvalidKeyExceptionForInit(KeyStoreCryptoOperationUtils.java:54)
W:     at android.security.keystore.KeyStoreCryptoOperationUtils.getExceptionForCipherInit(KeyStoreCryptoOperationUtils.java:89)
W:     at android.security.keystore.AndroidKeyStoreCipherSpiBase.ensureKeystoreOperationInitialized(AndroidKeyStoreCipherSpiBase.java:265)
W:     at android.security.keystore.AndroidKeyStoreCipherSpiBase.engineInit(AndroidKeyStoreCipherSpiBase.java:148)
W:     at javax.crypto.Cipher.tryTransformWithProvider(Cipher.java:2973)
W:     at javax.crypto.Cipher.tryCombinations(Cipher.java:2884)
W:     at javax.crypto.Cipher$SpiAndProviderUpdater.updateAndGetSpiAndProvider(Cipher.java:2789)
W:     at javax.crypto.Cipher.chooseProvider(Cipher.java:956)
W:     at javax.crypto.Cipher.init(Cipher.java:1329)
W:     at javax.crypto.Cipher.init(Cipher.java:1267)
W:     at devliving.online.securedpreferencestore.EncryptionManager.encryptAES(EncryptionManager.java:324)
W:     at devliving.online.securedpreferencestore.EncryptionManager.encrypt(EncryptionManager.java:168)
W:     at devliving.online.securedpreferencestore.EncryptionManager.encrypt(EncryptionManager.java:213)
W:     at devliving.online.securedpreferencestore.SecuredPreferenceStore$Editor.putString(SecuredPreferenceStore.java:205)

Now when i change the timezone on my device to be an offset of 0, I do not get this exception. Where I am currently is +1 timezone.

I believe the problem originates in the generateAESKey() method at line 483 where the start date is retrieved. Rather than setting the start validity to this local date, I think its meant to be set in UTC format.

[StuStirling]

Any thoughts on this? I couldn't find any documentation to say whether a validity start date needs to be set in local or UTC time?

[iamMehedi]

I haven't been able to reproduce it yet. A certificate validity date check shouldn't be locale dependent or specific, will see if I can find something in the docs.

[StuStirling]

I've tried to find in the source where the exception gets thrown but I can't find it.

From the Android docs however, it does say:

By default, the key is valid at any instant.

In this case, do we need to set a start date? This would solve this issue.

[patrickyin]

I got this error on Pixel android 8.0, only on this device. android 8.0 on nexus 5X and emulator work well

[iamMehedi]

@StuStirling @eetech can you please make a fork of the lib and check if not setting the start and end date resolve this issue?

[3Goldjungen]

On my Nexus 5 I can reproduce it:

• make force stop in the Android-App settings
• clear all data in the Android-App settings
• start the app -> KeyNotYetValidException

[oikmar]

this happens on Pixel2 as well. with version 0.5.1

[StuStirling]

@3Goldjungen as you can reproduce the issue reliably, could you checkout my branch and see if removing the start and end validity dates has fixed the issue? - https://github.com/StuStirling/Secured-Preference-Store/tree/issue/15

[StuStirling]

@oikmar @3Goldjungen @patrickyin is there any chance you could run my branch located here to see if it resolves the issue? https://github.com/StuStirling/Secured-Preference-Store/tree/issue/15

[oikmar]

@StuStirling unfortunately, we have moved on from this implementation. if i get to dig up the old code (time permitting), i will update here.

[carterhudson]

I encountered the same issue in a completely separate project that handles shared preferences & keystore in the same manner and can confirm the solution @StuStirling posted is working for me.

[iamMehedi]

@StuStirling can you please create a pull request with the fix?

[StuStirling]

@iamMehedi I can see that you have reverted the change I made to the start and end date key generation with good reason due to issues #31 and #32. However this means this issue will come back.

The problem we have is if you set the start date to now, and then change your timezone to be less than the timezone used to create the key, you get a KeyNotValidYetException.

Could a potential solution be to set the start date to the lowest timezone you could possibly set, for example if you are in -9 then we set the start date to be in the -12 timezone?

[iamMehedi]

@StuStirling I'll definitely look into that solution, hope that'd work.

[ghost]

@iamMehedi , I think for now that solution would fix it but would be nice to be able to have something that detects if timezone changes. I will look to see if something like that can be done in a way the data is not compromised.

[iamMehedi]

@StuStirling can you please test if 1fbdab3 fixes it? I have tested it on a couple of devices and it works fine.

[cornucopib]

@iamMehedi Any other questions? Can you close this isssue?

[iamMehedi]

@Vector-SMG Are you suggesting that you've tested it on a OnePlus 3T and the issue is resolved?

[cornucopib]

@iamMehedi http://remote.utest.21kunpeng.com/deviceSearch?type=remote，I hope this Can help you.

[cornucopib]

@iamMehedi Don't worry, it will start giving you some u's for free trial