5ec1cff/TrickyStore

attest key feature

Closed this issue ยท 6 comments

Since the key attestation can hardly be tampered with attest key feature, and also the project not support it , is there any remedial measure to handle that , such as disabling the feature without instruding the target App.

Well, the 4th and 5th certs seem to be similar and all contains key attestation extension. Technically, the attest key cert itself can be resigned just as the lead cert and the leaf cert can be resigned using the attest key in keystore while I am not sure is it practical to invoke signing using App's attest key with attest PURPOSE in hook component? Theoretically, the attest key feature could be handled, but I have no idea what a big challenge it is and is there any plan to do that in this project or just disable the attest feature? @5ec1cff

I'm guessing that as things are, even if apps that verify key extension data locally see spoofed values, eg boot state = Verified (locked, Google/OEM signed), apps properly doing verification server side will still see real values, eg Unverified (unlocked)...

I'm just trying to confirm this... @Gunkkk, is a remedy for this (ie. a fix to properly spoof hardware-backed key pair data for apps following Key Attestation model) your aim here? ๐Ÿ‘

I'm guessing that as things are, even if apps that verify key extension data locally see spoofed values, eg boot state = Verified (locked, Google/OEM signed), apps properly doing verification server side will still see real values, eg Unverified (unlocked)...

I'm just trying to confirm this... @Gunkkk, is a remedy for this (ie. a fix to properly spoof hardware-backed key pair data for apps following Key Attestation model) your aim here? ๐Ÿ‘

I'm afraid that you misunderstanded me and the keyattestation. With perfect keyattestation spoofed, the App can hardly get the true extension data unless they can get the authentation from OEMs.

Ah... So as things are, apps properly doing verification server side won't get any attestation data?... So we need a bypass since verification will fall? ๐Ÿค”

Ah... So as things are, apps properly doing verification server side won't get any attestation data?... So we need a bypass since verification will fall? ๐Ÿค”

@pndwal The precondition is that you have a good keybox. And the App can never get true attestation data without the help of OEMs in older Android versions.
Well the issue means that some advanced feature like APP attest key or RKP may enhance their verification and the Project will be useless with perfert verification of Apps under such threat assumpation. But theoretically, the feature like appattestkey can still be handled with additional hard work.

Fixed in 1.1.0!

@Gunkkk You may close this as completed. ๐Ÿ‘