First of all, I understand your taking offense (though none was intended) since this is the thing you work on. I feel the same way about stuff I work on! Second, I simply used that as a straightforward example, not to say "Apple good, android bad."
Security is always a risk tradeoff. My house uses special Medeco keys (modified in violation of the Medeco license as it happens) because what I want to defend against is copying when I lend out one of my numbered keys. The house is made of glass so someone could just use a brick to get in. For someone else this is a dumb tradeoff; for me it is appropriate.
And your message includes an example of such a tradeoff:
>This may not be as elegant as doing matching on the sensor, but keep in mind we have to play within the constraints of 2 difference vendors (SoC, Fingerprint Sensor).
>Somehow implying that Android is less somehow less secure in the case of fingerprint is disingenuous.
The channel between the two separate devices is an attack surface (as is the opportunity for offline attack on the encrypted data in the filesystem). The Android team has made the determination that that's an acceptable risk. I won't argue -- perhaps I agree and perhaps I don't, but it is unambiguously less secure than the single, all-encompassing approach. To claim so is hardly disingenuous.
Of course, as with my house, this just changes the class of attack. On either platforms you can consider attacking whatever authentication module talks to the TEE. Both systems use other mechanisms for that.
Finally, in the Android case a vendor is free to do what they want, especially if they don't care about access to branding, google services etc. Google branded devices have a more important brand to defend than, say, Asus (not to pick on Asus), much less, say, DJI's drones, for which the Android branding is utterly irrelevant (conceivably that could rebound on Google though personally I doubt it would even happen. The same obviously can't be said about iOS :-)
I think they were trying to deescalate, and your reply is more aggressive than necessary.
FWIW, "disingenuous" carries the connotation of intentional deception, i. e. making an argument in bad faith, because one knows that it's wrong.
In this case, I can understand where the defence of Android's implementation is coming from: the original description amounted to "plain text in the filesystem, but the name ends in .mp3 so nobody will find it", whereas the reality seems to be a slightly less elegant solution that can probably be subverted by a dedicated nation-state, but is unlikely to ever make a difference in most people's lives.
> My house uses special Medeco keys (modified in violation of the Medeco license as it happens) because what I want to defend against is copying when I lend out one of my numbered keys.
I would like to hear more about these modifications.
If you want stringent key control at the consumer level, I've found a good one in Abloy's Protec2 system, with a Ruby Abloy dealer. Under that system, an exclusive key blank is manufactured and made only available to a specific dealer. No other Abloy dealer is able to get that blank. [1] Put a Drumm Geminy Shield in front of a Protec2 cylinder to put a long delay on typical hand-held destructive attacks against the cylinder, or force an attacker to bring in heavy equipment to break the lock, and most attackers will opt for either softer targets or a brick through the window.
That key system also lets you do the usual key control designing, like a master key that opens everything, and a loaner key that only opens the front door, for example. Like any security system, you will want defense in depth, and have other layers protecting other aspects.
Security is always a risk tradeoff. My house uses special Medeco keys (modified in violation of the Medeco license as it happens) because what I want to defend against is copying when I lend out one of my numbered keys. The house is made of glass so someone could just use a brick to get in. For someone else this is a dumb tradeoff; for me it is appropriate.
And your message includes an example of such a tradeoff:
>This may not be as elegant as doing matching on the sensor, but keep in mind we have to play within the constraints of 2 difference vendors (SoC, Fingerprint Sensor).
>Somehow implying that Android is less somehow less secure in the case of fingerprint is disingenuous.
The channel between the two separate devices is an attack surface (as is the opportunity for offline attack on the encrypted data in the filesystem). The Android team has made the determination that that's an acceptable risk. I won't argue -- perhaps I agree and perhaps I don't, but it is unambiguously less secure than the single, all-encompassing approach. To claim so is hardly disingenuous.
Of course, as with my house, this just changes the class of attack. On either platforms you can consider attacking whatever authentication module talks to the TEE. Both systems use other mechanisms for that.
Finally, in the Android case a vendor is free to do what they want, especially if they don't care about access to branding, google services etc. Google branded devices have a more important brand to defend than, say, Asus (not to pick on Asus), much less, say, DJI's drones, for which the Android branding is utterly irrelevant (conceivably that could rebound on Google though personally I doubt it would even happen. The same obviously can't be said about iOS :-)