I could automate it way more than I currently do. At the moment, I just copy the certificate chains into a special local branch of Auditor and run that to output the relevant data and then test that it works properly. Need to do it for both the TEE and StrongBox certificates.
Conversation
I think that GM1913 sample was the most recent valid sample submitted. There was also a Mi MIX 2S submission claiming to have a green boot state but the attestation information says that the bootloader isn't locked, so it's either broken or has some kind of rootkit on it.
1
Both devices with valid samples supported since version 11 are now supported by the new stable release:
Quote Tweet
Auditor app version 12 released:
github.com/GrapheneOS/Aud
This release adds support for the OnePlus 6 A6003 and OnePlus 7 Pro GM1913.
See attestation.app/about and attestation.app/tutorial for info about the app and optional monitoring service.
1
Verifying a OnePlus 7 Pro, verification fails. I submitted a new sample.
1
1
There was an OS update between the first and second samples, so I hope they don't change the key at every update…
1
Replying to
The verified boot key never changes and the fingerprint is a hash of it so it doesn't change unless there's an update to the algorithm used to calculate it which shouldn't really be done once a device is shipped. Make sure you have Auditor version 12 on both Auditee and Auditor.
2
Replying to
That was it, the Auditor device didn't have version 12, but the version from Google Play
1
Isn't the vendor patch level weird? I can't believe they didn't update *any* vendor blob since last August, since the device shipped last month.
1
Replying to
Yes, that's meaningless right now because none of the vendors (including Google) is bothering to update VENDOR_SECURITY_PATCH. You can see that they have the wrong value set by running `getprop ro.vendor.build.security_patch` which is what gets sent to the keystore in early boot.
I update it properly for GrapheneOS though, and I've tried reporting the issue to Google to get them to start updating the property. They thought I was trying to get a bug bounty for reporting it and rejected it as a vulnerability. I'll try reporting it another way at some point.
1
By the way, the identity is just the sha256 of the app's persistent key in the keystore so it's not really private information. It's only unique to each pairing and will be a new value for every pairing. If you do it again you'll see it performs a strong paired verification.
1
1
Show replies