Auditor is finally going to be using the StrongBox Keymaster by default for new pairings:
github.com/GrapheneOS/Aud
Existing pairings will continue using the traditional TEE-based keymaster for compatibility due to verified boot key fingerprint and certificate chain pinning.
Conversation
This is where Auditor decides if it should use StrongBox:
github.com/GrapheneOS/Aud
It relies on certificates now having title=StrongBox or title=TEE since that's easier to check to quickly differentiate them rather than parsing the attestation extension:
1
Here's an example of a Pixel 3 XL with GrapheneOS paired with my account on the attestation.app device monitoring service using keys in StrongBox.
Auditor and AttestationServer have a very solid foundation and are steadily getting better. Going to improve the UX a lot.
1
1
3
Replying to
After updating the attestation-server an existing pairing displayed 'Failed to fetch device data.' Is this expected?
2
Replying to
Yes, that's expected. The server needs a column added for the new functionality. I haven't added the necessary upgrade code yet. You can do it manually for now:
sqlite3 attestation.db 'ALTER TABLE Devices ADD COLUMN pinnedSecurityLevel INTEGER NOT NULL DEFAULT 1;'
1
1
There aren't tagged releases for the AttestationServer yet, but the master branch is definitely a development branch and isn't guaranteed to provide full functionality for every revision. I haven't bothered including database upgrade code in AttestationServer yet but I can start.
1
Once there are tagged releases, it can be tested between each of the releases. There are no guarantees running the development branch of Auditor and AttestationServer though. Backwards / forwards compatibility is only going to be guaranteed between the actual tagged releases.