tink icon indicating copy to clipboard operation
tink copied to clipboard

com.google.crypto.tink.shaded.protobuf.InvalidProtocolBufferException: Protocol message contained an invalid tag (zero).

Open snehas13 opened this issue 3 years ago • 11 comments

We have been facing below exception in our production app with Tink library version 1.4.0.

Caused by: com.google.crypto.tink.shaded.protobuf.InvalidProtocolBufferException: Protocol message contained an invalid tag (zero). at com.google.crypto.tink.shaded.protobuf.y.C(SourceFile:10) at com.google.crypto.tink.shaded.protobuf.y.z(SourceFile:2)

Device And OS: Google Pixel 4a, OS Level 30

Note: We are unable to reproduce this issue from our end. It is reproducible for one of the user.

Please let us know if this issue has been fixed in the latest 1.6.0 library version.

snehas13 avatar May 19 '21 07:05 snehas13

Can you show me how you're calling into Tink?

thaidn avatar May 24 '21 06:05 thaidn

com.google.crypto.tink.shaded.protobuf.GeneratedMessageLite.parsePartialFrom (GeneratedMessageLite.java:1566) com.google.crypto.tink.integration.android.AndroidKeysetManager$Builder.build (AndroidKeysetManager.java:230) com.efe.user.dataSecurity.KeyStoreTinkManager.getOrGenerateNewKeysetHandle (KeyStoreTinkManager.java:43) com.efe.user.dataSecurity.KeyStoreTinkManager. (KeyStoreTinkManager.java:35) com.efe.user.di.modules.SecurityModuleKt$securityModule$1$1.invoke (SecurityModuleKt.java:18) com.efe.user.di.modules.SecurityModuleKt$securityModule$1$1.invoke (SecurityModuleKt.java:4)

Sending the above further stack trace.

Issue is reproducible only in Pixel 4a, Pixel 4 XL Pixel 4a (5G)

CodeSnippet:

init { TinkConfig.register() mAead = getOrGenerateNewKeysetHandle().getPrimitive(Aead::class.java) }

private fun getOrGenerateNewKeysetHandle(): KeysetHandle { return AndroidKeysetManager.Builder() .withSharedPref(app, tinkKeySetName, PrefFile) .withKeyTemplate(AesGcmKeyManager.aes256GcmTemplate()) .withMasterKeyUri(masterKeyUri) .build() .keysetHandle }

snehas13 avatar May 24 '21 09:05 snehas13

@thaidn @chuckx any update on this issue?

snehas13 avatar May 26 '21 01:05 snehas13

@thaidn @chuckx Can you please let us know the root cause of the issue.

snehas13 avatar Jun 03 '21 01:06 snehas13

@thaidn @chuckx Since we have planned for production release. Could you update us on this issue?

snehas13 avatar Jun 08 '21 06:06 snehas13

@snehas13

The root cause is in Android Keystore which has been found to be buggy. A workaround is to disable Android Keystore integration, by not specifying a master key URI:

private fun getOrGenerateNewKeysetHandle(): KeysetHandle {
return AndroidKeysetManager.Builder()
.withSharedPref(app, tinkKeySetName, PrefFile)
.withKeyTemplate(AesGcmKeyManager.aes256GcmTemplate())
.build()
.keysetHandle
}

This means Tink keys are stored in Shared Preferences unencrypted. See this comment for why this is secure enough for most users and devices.

thaidn avatar Jun 08 '21 07:06 thaidn

@thaidn The workaround is not feasible since we do not know which device is how much secure. If we do not use master key, then our sensitive information might be leaked and also app cannot decrypt the sensitive information which is already stored with master key in previous versions. Is it possible to add some retry mechanism for this exception in tink library? or clear the existing encrypted information if this error occurs?

Is tink working on resolving below errors? https://issuetracker.google.com/issues/158234058#comment48 https://github.com/google/tink/issues/413

snehas13 avatar Jul 05 '21 02:07 snehas13

@thaidn @chuckx

As per below doc,

Since Android Keystore is unreliable on certain devices. Tink runs a self-test to detect such problems and disables Android Keystore accordingly, even if a master key URI is set.

https://google.github.io/tink/javadoc/tink-android/HEAD-SNAPSHOT/com/google/crypto/tink/integration/android/AndroidKeysetManager.html

Let me know if latest library handles such scenarios. Since we have next production release planned in a week. Please respond ASAP

snehas13 avatar Jul 07 '21 02:07 snehas13

Was there any update on this issue? I'm having the same issue.

jpark318 avatar Sep 09 '21 16:09 jpark318

This exception can be thrown when your app get's restored from a backup. The keystore doesn't have the keys to decrypt the EncryptedSharedPreferences. Our app has set android:allowBackup="false" but this get's ignored when user uses a device to device migration. After the migration EncryptedSharedPreferences.create will throw this error.

lpappalettera avatar Feb 01 '22 07:02 lpappalettera

@lpappalettera is new update for security from jetpack solve current issue or not? https://developer.android.com/jetpack/androidx/releases/security#version_100_3

MahmoudMabrok avatar Mar 13 '22 13:03 MahmoudMabrok

I have deleted the app cleared everything nothing worked, until I changed the filename:

EncryptedSharedPreferences.create( ctx, "secret_shared_prefs_1", //Changed this one getMasterKey(ctx), EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV, EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM )

This might help somebody so I am posting it.

ssSFrankSss avatar Oct 18 '22 10:10 ssSFrankSss

Nothing new on this issue? Production crashes are piling up because of this issue ...

VincentTe avatar Feb 16 '23 09:02 VincentTe

I did do some changes to the AndroidKeysetManager lately that should help with this error: https://github.com/google/tink/commits/master/java_src/src/main/java/com/google/crypto/tink/integration/android

  • I fixed some race-conditions. So hopefully in many cases there will not be an error anymore.
  • I made the error messages better. So if this still fails, you will probably not get this protobuf error anymore, but a different, more meaningful error.

One cause of this error (as mentioned above) is when a backup is restored. Then, you have some encrypted data from your backup but the master-key that was stored in android keystore is not present anymore. There is no way for us to recover from this. You need to be prepared to handle this yourself. For example, by telling the user and deleting the data that can't be read anymore.

We will soon make a new release of Tink, and I think also the androidx security will also soon afterwards get a new release.

juergw avatar Feb 17 '23 08:02 juergw

I understand you cannot recover from a backup. But someone also mentioned that even with android:allowBackup="false", we still have this error but we shouldn't right? Or am I missing something?

VincentTe avatar Feb 17 '23 08:02 VincentTe

There is now a new version 1.8.0 of Tink that fixes some race conditions that might have caused this. For android security, there is the version 1.1.0-alpha05 that also fixes a similar race condition. Please upgrade to these vesions. I hope it works then. There is the possibility that this still fails because of a buggy keystore implementation on some phones. I don't have a solution for these cases.

See https://github.com/tink-crypto/tink-java/releases/tag/v1.8.0 and https://developer.android.com/jetpack/androidx/releases/security.

juergw avatar Mar 21 '23 08:03 juergw

There is now androidx security version 1.1.0-alpha06 that uses Tink 1.8.0 by default.

juergw avatar Apr 26 '23 16:04 juergw

I'm closing this now. If there are any other problems, please open a new issue.

juergw avatar May 11 '23 08:05 juergw