Add support for the Samsung Galaxy Z Flip3 5G (SM-F711B)

[dbaxa]

Signed-off-by: David Black [email protected]

[dbaxa]

cc @thestinger

[ghost]

Have you tested this with your own local builds of Auditor?

[dbaxa]

Have you tested this with your own local builds of Auditor?

Yes.

[ghost]

Make a PR to add it to attestation.app here as well: https://github.com/GrapheneOS/AttestationServer/

If you need a server to test I can spin up my instance, though it should be fine.

[dbaxa]

I have raised GrapheneOS/AttestationServer#187

[thestinger]

We need a project member to verify this and we're not set up for that right now. We're supposed to be doing this ourselves with the submitted samples, but we lack the resources to do it. We're also supposed to be adding samples for each added device to our samples repository which is important for maintenance. We stopped doing it for Pixels due to no longer actively using the actual sample submissions primarily due to lack of tooling.

If you want us to add more devices, what you should work on is making better tooling for automating this work including the sample handling so we can add all the devices with valid submitted samples instead of just one specific device.

I don't think we can accept these pull requests. It needs to be done in a different way.

[dbaxa]

Hi @thestinger,
What kind of automation would we like to end up having though?

It seems like for security reasons we end up having the "properties" (verifiedBootKey) and "attributes" (version info & backing type) in a relatively easy accessible fashion from samples - would the automation make it easy to raise PRs for the different repos and or update some kind of (mostly shared) state/database containing device related information?

[thestinger]

The main thing that needs to be done is verifying that it's a valid sample based on one of Google's roots and extracting the different properties from, along with testing that it passes verification with all the usual verification code. Sometimes there are bugs which you can see with our workaround setup for some older Samsung devices. It seems that isn't needed anymore if this works without it.

[thestinger]

Also, we need to test verifying both with and without StrongBox. Auditor will only use StrongBox but I like to know that we have the correct setup for TEE too. It can be a different attestation version, etc. which was often the case on Pixels before the Pixel 6 since it was Qualcomm's QSEE TEE implementation and the Titan M so Google was often ahead of Qualcomm.

[dbaxa]

Also, we need to test verifying both with and without StrongBox. Auditor will only use StrongBox but I like to know that we have the correct setup for TEE too.

Interesting. Do we have reason to check without strongbox - even for testing a correct TEE setup ... if strong box is available for a device?

[dbaxa]

The main thing that needs to be done is verifying that it's a valid sample based on one of Google's roots and extracting the different properties from, along with testing that it passes verification with all the usual verification code

So that would occur on/in https://github.com/GrapheneOS/AttestationServer right?
(Is there a way to download samples that the main server has received for testing purposes, https://github.com/GrapheneOS/AttestationSamples hasn't been updated in a fairly long time, ?)

Sometimes there are bugs which you can see with our workaround setup for some older Samsung devices. It seems that isn't needed anymore if this works without it.

Yeah I saw that. This device works without the workaround it seems.

[dbaxa]

@thestinger ^ is it possible to add some more details to this so that others might work on possible changes/automation?

[thestinger]

I can try providing some more details later.

[dbaxa]

Nudge @thestinger :-)

[khartmann97]

@dbaxa How did you get these hashes from your device - I'd like to get them for mine too.

[dbaxa]

Hi @khartmann97 - I think I made use of https://github.com/dbaxa/Auditor/tree/debug-setup-for-adding-new-device to get the information I needed.

[thestinger]

We're going to add generic device support instead of the previous approach. It's in development already:

#236