grapheneos / auditor Goto Github PK

This is currently very low priority because the Pixel intermediate is pinned and the batch certificates aren't narrowly scoped enough. The security is coming from keys being hardware-backed, not so much the certificate chain.

Most of this will require OS integration so most of the features would only be available for GrapheneOS.

If you don't scan the result, you'll need to clear pairings on either auditor end or auditee end to start the pairing process over again.

At the moment, they get screwed up in landscape mode. The QR code should probably be moved all the way to the right side or the left side so there's room to have the label. At the moment, the image view / bitmap ends up on top of the text view so it can overlap.

It's too painful to use AsyncTask correctly for this.

Ideally, it would be possible to ask for a battery optimization exception with a way to set the jobs as not being deferred similar to the option available for alarms. Unfortunately, the functionality isn't available.

It would be better to pass along the invalid attestation for the Auditor to see it, especially for the service. This will require some tweaks.

6/8 or more of the smaller dimension instead of 5/8

It might make sense to check that the app on the other end has a matching package name and signing key rather than hard-wiring them but that makes the code a bit less reusable.

To help with assigning errors to the right device.

It may not be wise to replace the TEE-based key and attestation. It would be nicer to have an additional StrongBox attestation alongside it, but it would cause a substantial increase in the size of the attestation message which would likely be painful / impractical with QR codes.

StrongBox support is implemented, so it just needs to be determined if it has any significant advantages / disadvantages for this use case.

It should start the attestation certificate chain with an app-specific intermediate generated once the app requests a key with attestation and kept unusable by the OS.

The certificate chain would go from generated attestation certificate -> batch intermediate -> device variant intermediate -> root to generated attestation certificate -> generated per-app intermediate -> batch intermediate -> device variant intermediate -> root without it opening up a new way of tracking identity.

The addition to the chain would end being part of what we pin, improving the guarantees offered by attestation. The provisioned intermediate being compromised doesn't need to prevent attestation from still being useful since we have pairing.

A future keymaster API level could also guarantee that the attestation certificate chain will be the same for keys generated by the same app to make it usable like this in a portable way.

We want to add support for submitting attestations via an account on a server. It will be implemented at https://github.com/GrapheneOS/AttestationServer, which is also where we already implement support for submitting samples. Devices paired with the account should be nicely listed out via a web interface. They have a nice provable unique identifier via the fingerprint of the hardware-backed key generated by the app already, which is not overly persistent/identifying like a serialno / IMEI.

The way it will work is the server will send an email alert if the device fails verification, fails to report in for a configured time period or falls behind on security patches.

For example, a device could be set to send an attestation weekly with alerts after 2 weeks of it not reporting in. The app can handle sending the attestations with a periodic JobScheduler job.

There's currently hardware attestation for the OS version and OS patch level. There's not much that can be done with the OS version automatically, but the OS patch level is incredibly useful for automatic alerts since devices shouldn't be falling far behind. Even if it's because the vendor isn't releasing updates rather than an attacker with root holding back upgrades, it's something a company probably wants to know about their fleet of devices.

A good default for Pixels would be alerts when a device is more than 1 months behind, i.e. when the 2018-05-05 patch level is released, it should be on at least 2018-04-05. Some devices would need more lenience if they take 2 months for non-AOSP fixes which is expected to be the case for some devices (i.e. enforcing 2018-04-01 patch level instead). The reality is that many don't get proper monthly security updates so non-Pixels may need a more conservative default like 3+ months. As long as it only warns once or twice, it should be okay.

It could eventually support other kinds of alerts like sending a Signal message.

By default, we'll use the same kind of information as the Auditor app, i.e. nothing sensitive like identifiers persisting past the Auditor app being uninstalled or having data cleared. It would make sense to offer the option of sending persistent identifiers for enterprise use though, and GrapheneOS might be able to use ID attestation if it bundles the app to actually have devices prove their IMEI / serialno. Can't see a reason anyone would want that for personal use though so perhaps it should only be exposed when using the Auditor app with our planned device manager. It's unclear how closely they should be paired together.

It currently uses offsets from the top and bottom which is strange.

I tried to verify the pixel 3 (GrapheneOS) with a pixel 3 stock.

The GrapheneOS phone successfully verified the stock

04-26 06:20:01.999 5658 5754 I Attestation: Parsing tag: [701], value: [18446744073709546693]

The release key being used for testing is a secp256r1 ECDSA (128-bit security) key with SHA256withECDSA signatures to match the curve and signing algorithm used within the app.

It probably doesn't make any sense to attempt any future proofing since Android is apparently going to be adding proper key rotation with APK Signature Scheme v3 and the Pixel 2 will almost certainly receive that since it has 3 major upgrades remaining.

It's too painful to use AsyncTask correctly for this.

Blockers: #47, GrapheneOS/os-issue-tracker#54.