Help - Attestation "Broken" After restoring from seedvault.

axino

Is it possible to do a seedvault restore after a successful auditor attestation and maintain that successful keypairing/attestation without clearing and redoing?

I setup a new device, did the attestation before anything. It had it's own pairing identity, different from the original GOS device I had setup and backed up owner profile.
After restoring my GOS owner profile, auditor keeps showing a java 400 error for the previously working remote attestation; the remote website doesn't show that any attempts have been made or failed after the restore.

No expectations of auditor being part of the seedvault backup.
My only guess would be that the "Pairing identity (hash of pinned hardware-backed key)" was altered on the device after restoring from seedvault?
The hardware boot key hash still matches; no changes.

other8026

axino I think you have to clear the old one and start again. I'll admit I don't understand Auditor that well, but this quote from the Auditor website makes me think it won't work:

The foundation of the Auditor app is generating a persistent key in the hardware-backed keystore

I don't believe the key would be backed up with Seedvault.

axino

other8026
It was that quote exactly that made me think it would work. It's why I setup attestation first before restoring, because I didn't think restoration would overwrite/impact the current paired identity.
Maybe I don't understand what "pinned hardware".
My limited understanding was it hashes a combination of the GOS hardware, the physical hardware, and likely something unique about the phone. If installing apps doesn't change that auditor test, a seedvault that doesn't capture/backup auditor anything shouldn't have either?

other8026

axino My limited understanding was it hashes a combination of the GOS hardware, the physical hardware, and likely something unique about the phone.

Based on what the site says and what I'm seeing in the Auditor app's code and Android documentation, the key is freshly generated. It's not a hash.

axino

other8026
I see. So the question is what triggers this to generate? Or why would a seedvault restore trigger to regenerate?

other8026

axino what triggers this to generate?

I believe it'll only generate if the app is pairing with a new device. I don't follow all of the encryption stuff involved with Auditor, but all the keystore stuff was using "generate" which leads me to believe it's all random. I didn't see hashes used as keys.

axino Or why would a seedvault restore trigger to regenerate?

I don't believe restoring with Seedvault will trigger anything like that.