The basic explanation is that it prevents binaries that are not signed by default from being loaded during the boot process. It only restricts the booting process in the uefi stage. If an executable has been modified, then it will not load due to secure boot. Technically there is nothing stopping you from modifying say winload.efi and signing it with your own key then adding that key to your bios keystore so that it will pass secure boot checks and still use secure boot.

I think the biggest thing is that the anticheat devs are using Microsoft's CA to check if your efi executable was signed by Microsoft. If that was the case then its all good and you are allowed to play the game you paid money for.

I haven't tested a self-signed secure boot for battlefield 6, I know some games literally do not care if you signed your own stuff, only if secure boot is actually enabled

edit: Someone else confirmed they require TPM to be enabled too meaning yeah, they are using remote attestation to verify the validity of the signed binary

Disclaimer: This is only an educated guess based upon public info. Also, it's impossible to make something truly unspoofable, but it isn't that hard to raise the bar for spoofing pretty high.

There are two additional concepts built upon the TPM and Secure Boot that matter here, known as Trusted Boot [1,2] and Remote Attestation [2].

Importantly, every TPM has an Endorsement Key (EK) built into it, which is really an asymmetric keypair, and the private key cannot be extracted through any normal means. The EK is accompanied by a certificate, which is signed by the hardware manufacturer and identifies the TPM model. The major manufacturers publish their certificate authorities [3].

So you can get the TPM to digitally sign a difficult-to-forge, time-stamped statement using its EK. Providing this statement along with the TPM's EK certificate on demand attests to a remote party that the system currently has a valid TPM and that the boot process wasn't tampered with.

Common spoofing techniques get defeated in various ways:

- Stale attestations will fail a simple timestamp check

- Forged attestations will have invalid signatures

- A fake TPM will not have a valid EK certificate, or its EK certificate will be self-signed, or its EK certificate will not have a widely recognized issuer

- Trusted Boot will generally expose the presence of obvious defeat mechanisms like virtualization and unsigned drivers

- DMA attacks can be thwarted by an IOMMU, the existence/lack of which can be exposed through Trusted Boot data as well

- If someone manages to extract an EK but shares it online, it will be obvious when it gets reused by multiple users

- If someone finds a vulnerability in a TPM model and shares it online, the model can be blacklisted

Even so, I can still think of an avenue of attack, which is to proxy RA requests to a different, uncompromised system's TPM. The tricky parts are figuring out how to intercept these requests on the compromised system, how to obtain them from the uncompromised system without running any suspicious software, and knowing what other details to spoof that might be obtained through other means but which would contradict the TPM's statement.

[1]: https://learn.microsoft.com/en-us/windows/security/operating...

[2]: https://docs.system-transparency.org/st-1.3.0/docs/selected-...

[3]: https://en.wikipedia.org/wiki/Trusted_Platform_Module#Endors...

They also require TPM, which I think facilitates remote attestation for secure boot.