[smoldesu]

Even if the chip didn't cooperate, Apple has the key derivation function and presumably everything used to generate your key. While we're on the topic of unlikely first-party attacks, it would be interesting to hear (or see) how Apple limits their ability to create duplicate keys.

[traceroute66]

> Apple has the key derivation function and presumably everything used to generate your key.

Nope.

The Secure Enclave still contains things like UID and GID which are fused into hardware at manufacturing and are not externally accessible, not even through debugging interfaces such as JTAG.

So Apple will never have all the input parameters for the key derivation functions.

And please, lets not go into tin-foil hat territory where you somehow think Apple logs all keys ever fused during manufacturing and then somehow ties these to you personally.

[Kirby64]

Unlikely. Having the key generation function is worthless, as you also would need the truly randomized nonce and salt used in any modern cryptographic function. There are plenty of methods to have truly unknowable functions even knowing exactly how the function is generated. That's the whole point of trustless security.

[numpad0]

Anyone's free to brute force encrypted data?

[croes]

Do you need to brute force the data, can't you simply intercept the data from the finger print sensor?

[numpad0]

Do they go through internal bus unencrypted?

[traceroute66]

> Do they go through internal bus unencrypted?

Of course not.

"The sensor captures the biometric image and securely transmits it to the Secure Enclave"[1]

IIRC the implementation detail is AES-GCM-256 with ECDH P-256, i.e. the biometric sensor and the secure enclave derive a unique session key via ECDH each and every time.

[1]https://support.apple.com/guide/security/face-id-and-touch-i...