Deciphering with Security token failed on receive error on hardware key decryption

[milogert]

On some files I go to decrypt with my YubiKey and it immediately returns an error that says:

Error: Deciphering with Security token failed on receive

Take away the Security Token anow and tough TRY AGAIN

Expected Behavior

It should decrypt the file with no error.

Current Behavior

I see the error

Error: Deciphering with Security token failed on receive

Take away the Security Token anow and tough TRY AGAIN

Steps to Reproduce (for bugs)

1. Somehow make a file corrupted in some way (I am not sure why some of my files are corrupted, seems to randomly happen).
2. Try to decrypt the corrupted file using a security key.
3. See the above error.

Context

I can't decrypt those files, which contain passwords.

I can however, decrypt them on a computer using normal GPG.

Unfortunately I can't provide files since I can't give password data away.

I am using OpenKeyChain through PasswordStore on Android.

Your Environment

• Android Version: 9, security update from 2018-12-05
• Device Model: Google Pixel XL
• OpenKeychain Version: 5.2 (52009)
• From Google Play or F-Droid?: Google Play

[JanMosigItemis]

Hi there, I encountered a similar issue:

I have 2 private keys set up. One for company, one for private accounts. Each key is residing on its own Yubikey.

First thing that is somewhat fishy: Both keys are listed with name "Jan Mosig", although card holder name and identities are different. I guess the name is heuristically extracted from the key's email addresses which of course contain my name.

Now when I send an encrypted mail from my private account to my company account, the decryption fails like described above:

    Error: Deciphering with Security token failed on receive

    Take away the Security Token anow and tough TRY AGAIN

However, when I try to decrypt a mail from a different person, everything is working fine. Decryption of "my" mail on PC via gpg and Enigmail works fine.

I guess it has something to do with both keys being listed as "Jan Mosig" and the decryption routine somehow confuses them because of this.

Suggestion (workaround): Add an option to edit the key's "name", so that they may be different.
Suggestion (fix): The key selection routine might need to be fixed.

Specs:

• OpenKeychain 5.2 (52009) (Google Play)
• Android 8.0.0 on Honor 9, latest updates installed.
• Yubikey 4 NEO

[milogert]

I don't have keys of the same name on my phone, but I do share a last name with a cousin of mine who's key I imported.

So my name is MyFirst MyMiddle OurLast and his is HisFirst OurLast, so perhaps that is semi-related?

Were you able to resolve by just removing one of the keys from your keychain? Lacking an option to change the name of they key that might provide some further information.

[JanMosigItemis]

I just tried and it turns out: If I delete my company key, and decrypt the mail with my personal key, it works. This does not make any sense, because the mail was send to my company account and should have been encrypted with my company pub key.

But obviously my personal pub key was chosen. So it seems, not only decryption but also encryption has problems with key selection.

[helinko]

I also saw this with a password in password-store (https://github.com/android-password-store/Android-Password-Store).

I have two keys both with my name and e-mail, one has a non-empty description though. Unfortunately my second key does not have NFC and I couldn't get it working through the USB port on my phone, so I couldn't verify whether it worked.

Both keys worked on my desktop with the same data. When I modified the password entry on my desktop and synced changes, I could once again decrypt it on the phone. It's not 100% reproducible though, I have another entry I created with the same setup few hours after the problematic one, and it works fine.

[helinko]

I've managed to reproduce this reliably now. Both keys have to be part of My keys for the bug to appear. I've previously had the second key as a normal public key. In both situations my name and e-mail are the same. Then, if I create a new password while both keys are selected for the password store, the password can't be decrypted on the phone, until it has been edited on the desktop.

[evgeny-mezin-epam]

That bug happens to me as well... Can't add more value to the topic atm

P.S.
issue persists disregarding of what channel to use OTG or NFC

[daniele-athome]

I'm having this issue as well (YubiKey 5 NFC), with both encrypted content generated from my pc with gnupg and encrypted content generated by OpenKeychain itself. Inspecting logcat isn't really helpful since the app doesn't log anything at all.
Is there some way to enable debug logging or getting something else useful from logcat? I have root access if needed.

The YubiKey works on my pc via USB. I haven't tried USB-OTG on my device though (will try ASAP and update this comment). My device is a Moto X4 with Android One stock firmware, Android 9.0.

UPDATE: USB-OTG works.

[daniele-athome]

Further investigation (app debugging) revealed that the YubiKey returns 0x6700 in ResponseApdu.getSw(). Looking around some specs on the Internet I found out that it means that either Lc or Le is wrong. Unfortunately I'm not even sure of that because different sources says different things about it (some say stuff like "wrong length" without specifying which length) and I can't access the official specs from ISO because it's behind a paywall.

After that I bumped into #2049 (comment) stating that different attempts were made with the Le field, so I tried methods 2, 3 and 4 with no success. I also tried method 1 but I'm not sure I did it correctly (I commented out the whole "ne" if block in the 4e case - that was the failing case - in CommandApdu and reduced the apdu array by 2). Interestly, the 4e case in CommandApdu is used in both encryption and decryption, but somehow decryption always fails.

I'm willing to help with some more debug if someone would point me to the right direction, that would be really appreciated.

UPDATE: using ECC keys on the Yubikey will fall in the 4s case and decryption will work (I was using RSA keys before, unfortunately I'm not planning to switch to ECC keys anytime soon). I guess this might very well be a firmware bug (as far as I can see OpenKeychain is adhering to standard).

UPDATE/2: forcing chaining mode (instead of extended length) will cause the same response (6700), so I can guess (?) it's not the way the data is sent, but rather the data itself causing the problem. Anyway I won't know for sure until I try with another device (I'll have my hands on it in a few days).

[holderl5]

I have 2 yubikeys with the same RSA key stored on each. I use Password Store on android to access my passwords from pass. Not too long ago, I had a huge problem where I could not access any passwords in the store from android. I found a command in pass to re-encrypt all passwords and that fixed the issue. I put the instructions in an issue tracker (I think on github), but unfortunately can't find them.

Today, I hit a similar problem, but with a different error message:

error deciphering with security token failed on receive

On checking the files on the desktop, if I go to ~/.password-store and see the problem right away:

~/.password-store$ file DOOFUS.gpg
DOOFUS.gpg: PGP RSA encrypted session key - keyid: ABCD 1234567 RSA (Encrypt or Sign) 4096b .
~/.password-store$ file OTHERDOOFUS.gpg
OTHERDOOFUS.gpg: GPG encrypted data

DOOFUS works, OTHERDOOFUS does not.

So similar problem to last time, I just need to find the command I used.

I will update this when I figure it out:

Figured it out. Reviewing the docs, it seemed reasonable that any edit would use the default key for the password store to encrypt the data. I edited the offending file, pushed to git, pulled from password store, and I no longer get this error. No idea why this file decided to become "corrupted".

Sorry for hijacking this thread, but I know others with this error will want to see. Hopefully this may give some clues as to what is happening in the original reporter's situation.

[daniele-athome]

Hi @holderl5, what firmware version do you have on your keys? Do you use your key via NFC or USB on your Android device? Brand and model? I'm trying to verify if the device is the problem or it's the key. Thank you!

[mintar]

This is the script you're looking for: android-password-store/Android-Password-Store#173 (comment)

[holderl5]

Hi @holderl5, what firmware version do you have on your keys? Do you use your key via NFC or USB on your Android device? Brand and model? I'm trying to verify if the device is the problem or it's the key. Thank you!

I have a Yubikey 5 Neo on the phone via NFC and a Yubikey 5 Nano on the the desktop inserted in the USB port. The problem went away after I fixed the file. After editing it with pass on the desktop, this is the outfile of file command:
~/.password-store$ file OTHERDOOFUS.gpg
OTHERDOOFUS.gpg: PGP RSA encrypted session key - keyid: ABCD 1234567 RSA (Encrypt or Sign) 4096b .

And I would add when I was using pass, that one file was the only password I could not decrypt on the phone.

Just based on that, it is possible that a similar problem may be plaguing the original poster. That is pure conjecture though.

[laomaiweng]

Hi, I'm in a similar case as several above: I have my private key on a Yubikey 5, a password store that I just reencrypted to my public key on the desktop and synced to my phone, can't decrypt some files with OpenKeychain on the phone with the same error as above (but works on the desktop).

I ran file on the whole password store and only 3 files identified as GPG encrypted data. Those 3 files indeed fail to decrypt on the phone. I did some random sampling through the other files and found none that failed to decrypt.

So I dug deeper and tried to parse those files. I wrote a basic & incomplete Python parser for PGP packets (here), but it's enough to highlight at least one difference:

• in files that fail to decrypt, the length of the first packet (the one that holds the session key for the file contents, encrypted to my public key) has a length of 523,
• in files that decrypt successfully on the phone, the length of that first packet is 524.

I don't know why/how those files ended up with a different length, and why this causes issues on the phone but not on the desktop. I may be able to dig a little bit deeper into the former, but I'll be out of my depth trying to understand the latter. :(

[laomaiweng]

Ok so I dug a bit deeper, this difference in length (523 for files that fail vs. 524 for files that succeed) is indeed probably random, as it looks like it depends on the value of the encryption of the session key under the recipient's public key: if 8 or more of the most significant bits of the ciphertext are 0, there'll be one less byte to encode (since leading 0s are stripped when encoding multi-precision integers in libgcrypt).
This explains why editing the file usually solves the problem: after re-encryption, it gets a new encrypted session key which likely doesn't have its 8 MSBs set to 0.

However, I'm not sure as to why this causes problems on the OpenKeychain side. Possibly this has to do with how Bouncy Castle decodes the PGP-encoded multi-precision integer, and/or with how it sends the data to decrypt to the Yubikey?
It probably does either of these differently than GnuPG on the desktop, which succeeds in decrypting the file, but I didn't go further analysing this.

As a workaround, I'll probably either add a git pre-commit hook to check the repo for files with a pubkey-encrypted session key packet with length 523, or just check once in a while the whole repo, and re-encrypt any offending files.

[laomaiweng]

For reference:

• in GnuPG
  • MPI encoding in PGP format happens in the else if (format == GCRYMPI_FMT_PGP) branch of the _gcry_mpi_print function in libgcrypt's mpi/mpicoder.c
  • pubkey-encrypted session key encoding happens in the do_pubkey_enc function in GnuPG's g10/build-packet.c
• in Bouncy Castle
  • MPI decoding happens in pg/src/main/java/org/bouncycastle/bcpg/MPInteger.java
  • pubkey-encrypted session key decoding happens pg/src/main/java/org/bouncycastle/bcpg/PublicKeyEncSessionPacket.java

[hashworks]

I also had a hand full of files that identified as "GPG encrypted data" which caused bugs in OpenKeychain. Find them with find, file and grep:

find ~/.password-store -type f -name "*.gpg" -exec file {} \; | grep "encrypted data"

I was able to "fix" them by editing them with gopass - afterwards they had the normal "PGP RSA encrypted session key" type.