Remote hardware attestation #46

TommyTran732 · 2022-01-31T09:00:10Z

TommyTran732
Jan 31, 2022

GrapheneOS has their Auditor app which can do both local attestation using another Android 8+ device and remote attestation with attestation.app. Having continuous device monitoring is actually quite nice. It would be awesome if DivestOS can have something like this.

If you are okay with the idea, we could:

Ask GrapheneOS to include DivestOS devices in their client and server. They have a few requirements like the OS must at least uphold the Android security model, have verified boot, not have signature spoofing, etc. None of which seems to be a problem with DivestOS as far as I know.
Fork the auditor app and setup DivestOS's own attestation server. If you do this, then you have full control over the infrastructure and don't have to rely on another project for support. It will, however, get annoying if other Android derivatives start doing the same thing, as there will be a bunch of auditor forks and doing local attestation between 2 different android derivatives would require installing 2 different versions of the auditor.

flawedworld · 2022-02-28T00:42:43Z

flawedworld
Feb 28, 2022

@SkewedZeppelin Please get in touch if you are interested in this, would be happy to help!

5 replies

SkewedZeppelin Feb 28, 2022
Maintainer

I'm not against this feature.
And it would be very nice to see.
The issues I have are:

I see no easy way to actually generate the data and there is very little documentation on it.
- there is just the option to submit sample data
- from my understanding you can't even trivially locally compile it, because it only works when it is signed with the official key
DivestOS has few tested working devices that meet the criteria
- for example I only have a 1st gen Pixel, 2 and 3 have been tested by others, 3a is very outdated because I can't compile 11 for it, 4/5 don't boot, and 6 isn't supported yet
- OnePlus 6 and 6T for example currently use the official stock vendor partition

flawedworld Feb 28, 2022

Device support would be a matter of doing the following for each device. Example values have been given for a Pixel 6 running the stock OS.

obtaining verified boot key SHA256's of DivestOS ("0F6E75C80183B5DEC074B0054D4271E99389EBE4B136B0819DE1F150BA0FF9D7")
obtaining device model name ("Google Pixel 6")
obtaining attestation version ("4")
obtaining keymaster version ("41")
if they use the older rollback resistance API (Pixel 2 and older) ("false")
if they have modern per-user encryption (basically near-everything) ("true")
if they have strongbox support ("true")

You can get attestation/keymaster versions quickly by compiling a dev build of Auditor, adding junk info (make them say 184 or whatever) and getting the real values via the logs it will produce. The TEE and strongbox based attestation may produce different values and you can force TEE based attestation by changing: https://github.com/GrapheneOS/Auditor/blob/f90109d2e2ddcee03ca3095f19ace7a826810b38/app/src/main/java/app/attestation/auditor/AttestationProtocol.java#L121

Here is the work we did for adding the Pixel 6 and 6 Pro for example:
GrapheneOS/Auditor@c5f9827
GrapheneOS/Auditor@4e377bc

GrapheneOS/AttestationServer@17ee0ff
GrapheneOS/AttestationServer@27d6a13

If you were to go about implementing support in DivestOS, the easiest route would be adding support for devices which you have access to, DivestOS has production OS support for and we already have infrastructure for in Auditor/AttestationServer in my opinion. You can test Auditor easily locally with 2 Android devices with your own builds and so long as you update the key within the code. If you nail that then AttestationServer becomes easier to do.

SkewedZeppelin Feb 28, 2022
Maintainer

OK
So I first created a list of the verified boot keys.
And here they are for reference: https://divestos.org/misc/verified_boot_public_key_hashes.txt
I verified they match the boot screen on mata and fajita. A user in my chat room also verified guacamole.
I could not figure out how to derive the one on my sailfish. Looks like SHA-1 but didn't match my script.

I then added fajita to Auditor, but immediately slammed into an error and can also reproduce it with the official Auditor app.
This appears to be an common issue where the attestation key can be lost?

02-27 22:29:41.024   577   577 E KeyMasterHalDevice: Attest key send cmd failed
02-27 22:29:41.024   577   577 E KeyMasterHalDevice: ret: 0
02-27 22:29:41.024   577   577 E KeyMasterHalDevice: resp->status: -10003
02-27 22:29:41.024  1122  5208 E keystore: Keymaster reported error: -10003
02-27 22:29:41.024  1122  5208 E keystore: NOTE: This is an error in the vendor specific error range.
02-27 22:29:41.024  1122  5208 E keystore:       Refer to the vendor of the implementation for details.
02-27 22:29:41.024  1122  5208 E keystore:       Implementation name: Keymaster HAL: 4
02-27 22:29:41.024  1122  5208 E keystore:       Vendor name:         QTI
02-27 22:29:41.024  1122  5208 E keystore:       MajorVersion:        
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: attestation generation error
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: java.io.IOException: java.security.ProviderException: Failed to generate attestation certificate chain
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	at app.attestation.auditor.AttestationProtocol.generateKeyPair(AttestationProtocol.java:1438)
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	at app.attestation.auditor.AttestationProtocol.generateSerialized(AttestationProtocol.java:1270)
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	at app.attestation.auditor.GenerateAttestationService.onHandleIntent(GenerateAttestationService.java:62)
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:77)
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	at android.os.Handler.dispatchMessage(Handler.java:106)
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	at android.os.Looper.loop(Looper.java:223)
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	at android.os.HandlerThread.run(HandlerThread.java:67)
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: Caused by: java.security.ProviderException: Failed to generate attestation certificate chain
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	at android.security.keystore.AndroidKeyStoreKeyPairGeneratorSpi.getAttestationChain(AndroidKeyStoreKeyPairGeneratorSpi.java:611)
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	at android.security.keystore.AndroidKeyStoreKeyPairGeneratorSpi.createCertificateChain(AndroidKeyStoreKeyPairGeneratorSpi.java:498)
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	at android.security.keystore.AndroidKeyStoreKeyPairGeneratorSpi.generateKeyPair(AndroidKeyStoreKeyPairGeneratorSpi.java:475)
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	at java.security.KeyPairGenerator$Delegate.generateKeyPair(KeyPairGenerator.java:727)
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	at app.attestation.auditor.AttestationProtocol.generateKeyPair(AttestationProtocol.java:1436)
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	... 6 more
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: Caused by: android.security.KeyStoreException: -10003
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	at android.security.KeyStore.getKeyStoreException(KeyStore.java:1301)
02-27 22:29:41.027  1907  5254 E GenerateAttestationService: 	... 11 more

I can't really continue, as I don't have any other supported devices.

flawedworld Feb 28, 2022

Seems like they screwed it up. Typical OnePlus.

flawedworld Feb 28, 2022

A lot of OEM's in particular incompetent ones like OnePlus ending up breaking attestation APIs with updates (or it never worked) and I highly suspect this is the case here.

flawedworld · 2022-04-07T00:55:05Z

flawedworld
Apr 7, 2022

Due to a bug in some OEM implementations of the Android keystore, you will need to copy this for some devices GrapheneOS-Archive/platform_system_security@74760ab

This affects the Pixel 3 and 3 XL at least