Unable to decrypt metadata encryption

[powellnorma]

This happens on multiple devices:

E KeyMasterHalDevice: Begin send cmd failed
E KeyMasterHalDevice: ret: 0
E KeyMasterHalDevice: resp->status: -62
E KeyMasterHalDevice: Upgrade key send cmd failed
E KeyMasterHalDevice: ret: 0
E KeyMasterHalDevice: resp->status: -38
E keystore2: keystore2::error: In create_operation: Failed to begin operation.
E keystore2: Caused by:
E keystore2:     0: In upgrade_keyblob_if_required_with: Upgrade failed.
E keystore2:     1: Error::Km(ErrorCode(-38))
E recovery: keystore2 Keystore createOperation returned service specific error:-38

Places where I saw this:

• https://forum.xda-developers.com/t/recovery-unofficial-twrp-gauguin-dhollmen.4471915/post-88536449
• https://forum.xda-developers.com/t/twrp-3-7-0-12-for-sunfish-testing.4179101/post-88978961
• [maple] keymaster related boot failure after OTA from 8.1.0_r26 to 8.1.0_r46 sonyxperiadev/bug_tracker#165 (comment)
• [Bug] TWRP XZ3 decryption broken (keymaster 4.0) MartinX3-AndroidDevelopment/bug_tracker#35 (comment)

The -62 means KM_ERROR_KEY_REQUIRES_UPGRADE, and -38 means ErrorCode.INVALID_ARGUMENT.

My first thought was that this happens when PLATFORM_SECURITY_PATCH is set too high, and thus this code reports to the caller that the key should be "upgraded" (which in succession fails):
https://android.googlesource.com/platform/system/keymaster/+/tags/android-12.1.0_r27/android_keymaster/android_keymaster.cpp#66

However even adjusting PLATFORM_SECURITY_PATCH to what my normal ROM is using, this kept happening.
I checked that my adjustment was working via these commands:

getprop ro.vendor.build.security_patch
getprop ro.build.version.security_patch

Unfortunately my Device (pixel 4a) uses an propitiatory keymaster implementation - Otherwise I would have tried to patch the previously mentioned function.

IMO the question is: Why does TWRP make the keymaster want to upgrade the key, and normal ROM does not?

[bigbiff]

Decryption should be device specific issues. What device is this so I can move it to the appropriate project?

We upgrade the key all the time because we do not want to mess with the key on /data/

We upgrade it in /tmp and use it there, and the key will exist simultaneously while TWRP decrypts with the upgraded key.

[powellnorma]

Decryption should be device specific issues. What device is this so I can move it to the appropriate project?

In my case its a pixel 4a, I use tnakamur/android_device_google_sunfish

We upgrade the key all the time because we do not want to mess with the key on /data/

Ah, that explains the high value for PLATFORM_SECURITY_PATCH. But why does it still try to upgrade the key even when I set PLATFORM_SECURITY_PATCH to the the value of the normal ROM?

AFAIU, the encrypted key is stored in a blob on the /metadata partition, and TEE generates a one-time key with which we can decrypt the blob. Is this correct? And why would the original key/blob (on /metadata) be changed when we don't upgrade the key? Would that mean that we can't access /data from the normal ROM anymore?

TWRP decrypts with the upgraded key

Do you by any chance have an idea/guess, why this upgrade is failing here?
E keystore2: 0: In upgrade_keyblob_if_required_with: Upgrade failed.
It seems to be an issue that is not only specific to the pixel 4a?

[bigbiff]

Sorry, we do not support the pixel 4a officially.

[powellnorma]

I understand - If anyone finds the time to answer some of my questions, I'd be really greatful! I am trying to get this working for some time now.

It feels to me as if this is a "bug"/situation which comes up on multiple different devices: Sony Xperia XZ3, Xiaomi Mi 10T Lite, Xperia XZ Premium, Pixel 4a

[powellnorma]

and thus this code reports to the caller that the key should be "upgraded" (which in succession fails):

I now think this is just the software KeyManager, the actual (propitiatory) QCom KeyManager gives its Tee Application some parameters, with which the TEE App then decides if an update is needed.

So AFAIU, one would have to figure out what parameters the QCom KeyManager passes to the QCom TEE app, and why they are different from normal ROM.

But since the QCom KeyManager propitiatory, I see no straightway to do this? However the Pixel 4 (and 3+5) are officially supported, and they probably also use a QCom KeyManager - So maybe one could look there for inspiration

[powellnorma]

@bigbiff I assume it does, but have you checked weather metadata decryption works on Pixel 4?

I saw your commit TeamWin/android_device_google_coral@4f6afd2 - Was that needed to get metadata decryption working on Pixel 4 A13?

I tried the same value for pixel4a, but sadly still the same problem

[bigbiff]

I haven't had time to look at the pixels in a while due to personal time constraints especially in A13.

[powellnorma]

What device is this so I can move it to the appropriate project?

Maybe it would be worth / make sense to open an Issue for Pixel 4 to check if A13 metadata decryption is working? So that once once you or someone else finds the time this is not forgotten. Maybe it also just works on the Pixel 4, and that issue can then be simply closed