Goodness - a lot of posts but not a lot of actual information.
The sensor and the secure enclave work on the basis of a shared key. The key is (I presume) baked into the sensor, but configurable (by Apple) in the enclave. The key is used to negotiate subsequent, unique session keys which are used to AES encrypt the fingerprint raster scan when it is sent from the sensor to the enclave. After arriving in the enclave and being decrypted it is hashed and compared to a list of existing hashes which represent registered fingerprints. A boolean (yes it matched, or no it didn't) is returned to the app which called the auth API to invoke Touch ID.
Shared key obviously has caveats, but asymmetric stuff like RSA/DH is simply too slow to be done quickly by an onboard crypto engine baked into discrete components like that; ever done a SCEP enrolment and seen how long the enclave takes to generate RSA keys? That would be useless for touch ID.
<Speculation>Even tapping the bus for raw binary going in and out of the CPU won't help you get access to the data, but if you knew what the shared key was you could probably reverse engineer the unique session keys. I don't know how well baked into the enclave/sensor the keys are, but it feels reasonable to assume there's a reason for Apple to be wary of the presence of a component whose key may be known to a malicious actor. Resetting the key inside the enclave is almost certainly done in software as the enclave is basically an HSM - doing so probably involves undocumented APIs and a request signed by an internal Apple certificate authority</Speculation>
If you replace the sensor you need to ensure the keys remain in sync or touch ID simply cannot function. Personally I'd favour an approach which wiped the enclave if there's a key mismatch. Apple have taken a somewhat more draconian approach so I suspect they must be aware of a theoretical attack vector. Given the damage to their business (not to mention potential loss to customers) which would occur if touch ID were compromised, I don't blame them for taking a very conservative approach.
Whilst I have not verified it personally, I'm told a DFU restore after refitting the original sensor will bring it back to life. Whether you still have the old sensor is another matter entirely; probably not! I've yet to see comment as to whether this occurs purely during restore, or whether the check is also made at runtime. If it's the former and you've still got the old sensor there could be a way out.
The sensor and the secure enclave work on the basis of a shared key. The key is (I presume) baked into the sensor, but configurable (by Apple) in the enclave. The key is used to negotiate subsequent, unique session keys which are used to AES encrypt the fingerprint raster scan when it is sent from the sensor to the enclave. After arriving in the enclave and being decrypted it is hashed and compared to a list of existing hashes which represent registered fingerprints. A boolean (yes it matched, or no it didn't) is returned to the app which called the auth API to invoke Touch ID.
Shared key obviously has caveats, but asymmetric stuff like RSA/DH is simply too slow to be done quickly by an onboard crypto engine baked into discrete components like that; ever done a SCEP enrolment and seen how long the enclave takes to generate RSA keys? That would be useless for touch ID.
<Speculation>Even tapping the bus for raw binary going in and out of the CPU won't help you get access to the data, but if you knew what the shared key was you could probably reverse engineer the unique session keys. I don't know how well baked into the enclave/sensor the keys are, but it feels reasonable to assume there's a reason for Apple to be wary of the presence of a component whose key may be known to a malicious actor. Resetting the key inside the enclave is almost certainly done in software as the enclave is basically an HSM - doing so probably involves undocumented APIs and a request signed by an internal Apple certificate authority</Speculation>
If you replace the sensor you need to ensure the keys remain in sync or touch ID simply cannot function. Personally I'd favour an approach which wiped the enclave if there's a key mismatch. Apple have taken a somewhat more draconian approach so I suspect they must be aware of a theoretical attack vector. Given the damage to their business (not to mention potential loss to customers) which would occur if touch ID were compromised, I don't blame them for taking a very conservative approach.
Whilst I have not verified it personally, I'm told a DFU restore after refitting the original sensor will bring it back to life. Whether you still have the old sensor is another matter entirely; probably not! I've yet to see comment as to whether this occurs purely during restore, or whether the check is also made at runtime. If it's the former and you've still got the old sensor there could be a way out.