supposedly, according to Apple, the secure enclave handles signature verification and authentication for the entire device, taking the CPU out of the equation
Unless Apple is wrong about how their own device works.
Yup, because a sensor that is disabled (power and data pins) when it fails to authenticate itself can totally prod at the rest of the system.
And if Apple's engineering is that weak, they deserve the criticism. If the secure enclave is truly write-only as Apple claims, if communication between the fingerprint reader and the secure enclave is encrypted as Apple claims, if a rolling secondary key is used as Apple claims, if the match decision is made within the secure enclave (as would be necessary if it is write-only)... see where I'm going with this?
The fingerprint scanner no longer working should tell the user that much, no need to brick the phone to do it. And it would be immediate, not weeks or months later when a system update is installed, like Error 53.
Would it not be possible for law enforcement to replace the real digitizer with one that reports "oh yeah, that's the fingerprint I know" whether or not my finger is being used?
According to Apple, who claims that the fingerprint data is irretrievably stored in the secure enclave (which, if you follow the logic, necessitates that the secure enclave make that decision), no. Of course, if replacing the home button is the security issue they're now claiming it is, it appears they're lying about that. Either way, they're lying.
How are you protected? You've unlocked your phone and they've cloned it prior to the repair that bricked it. The bad guys have you data, but you no longer do.
just look at car security devices that are paired to each other like key readers and electronic steering wheel locks.
Yes, look at those indeed. They don't brick the car, you can have it towed to a dealership, get the pairing updated, and drive off. Apple, on the other hand, won't update the pairing unless they also do the repair; therein lies the problem.
If the switch is a modular component, then it can be swapped out for one that will let the bad guy drive my car away, or a signal (perhaps a replay attack) can be passed down the bus.
The first assertion you make here is flat-out wrong, which you seem to realize in your second assertion. The ECU makes the "start/no-start" decision and replacing the ignition switch cannot change that. In the case of a replay attack, the malicious part would need something to replay; that means a valid key would need to be inserted. In order to pull this off, the 'bad guy' would need to break into your car, remove the ignition, transfer the key pattern to his malicious replay-enabled ignition, and install that, all quickly enough to not be seen and without damage so you don't notice; he, then, would have to wait for you to start the car at least once, then would have to break in again to steal the car. All of this could be mitigated by cryptographically pairing the ignition switch to the ECU so the malicious part can't successfully record the exchange between the key and ECU in the first place, and requiring a dealership visit to pair a new ignition or key (this is what they already do); it can be further mitigated by using a secondary key which changes for each transaction, so even if a successful recording is made, a replay is impossible.
And that's precisely what Apple claims to be doing.
You also have to remember the original stated reason for the sensor being paired to the iPhone, which is that slight manufacturing differences from one sensor to the next necessitate that each sensor's output is different. The same applies to the sensors on the Nexus 5X and 6P, being based on the same technology. This renders the fingerprint data useless for any purpose other than verifying whether the hash sent by the sensor (and I mean the exact same sensor) matches or not. It can't be used to recreate, even partially, someone's fingerprint. Beyond that, the Nexus devices in question utilize dedicated security storage, similar to Apple's secure enclave.
Thankfully, Huawei and Google have learned plenty from the past and the Nexus 6P does not fall into the insecure fingerprint implementation trap. Nexus Imprint adopts a very similar approach to Apple’s Secure Element for Touch ID; this hardware partitioning provides the kind of isolation that is required to nullify the exploits that would have been possible with earlier fingerprint implementations such as found on the HTC One Max.
So, not only are you wrong about what the 'other side' does, you're wrong about what it means.
If communication between the sensor and the secure enclave is encrypted (and with a rolling secondary key, which prevents replay attacks) and data cannot be retrieved from the secure enclave, as Apple is telling us, there is no reason to disable anything but the power and data pins for the sensor if it fails to authenticate itself to the secure enclave at boot. Period. Let it be a dumb button if it doesn't authenticate; if you remove power and data lines from the button, you remove any possibility of a security vulnerability.
But, but... but... can't it just keep trying to authenticate until it's successful? Sure, it can, once per reboot (this is why one should disable the power and data pins on failure). A few quadrillion reboots and it'll finally get in.
This. Fingerprint + PIN would be protected ad the PIN is something you know. Password + PIN for when the fingerprint sensor fails, still protected as it's something you know, rather than something you are.
Considering that it wasn't an issue until iOS 9, I'm gonna go ahead and conclude it's entirely done in software. Idiocy or malice I do not know, but I do know it's unnecessary; supposedly, according to Apple, the secure enclave handles signature verification and authentication for the entire device, taking the CPU out of the equation.
But the CPU and sensor are paired up because you don't want to send the sensor data unencrypted across the bus where it's then subject to spoofing attacks.
Wrong. Supposedly, the fingerprint data is stored in the secure enclave and can not be retrieved. The sensor and secure enclave are paired (the secure enclave and CPU likely are, as well), at least according to Apple, and the match decision of made by the secure enclave.
Now that that's been cleared up, there is no reason to brick the device if the sensor fails to authenticate itself; just don't talk to the sensor anymore. Shut down its power and data lines and turn it into a dumb button like it was on the iPhone 5 and earlier; PIN still works.
Supposedly it is, because the fingerprint hashes aren't supposed to be able to be read from the secure enclave once they've been stored. That necessitates that the secure enclave make the match decision. Technically, leaving it at that doesn't allow for easy secure replacement of the sensor; however, we are told that communication between the sensor and secure enclave is encrypted, and that there is a secondary (rolling) key exchange to prevent replay attacks so, yeah... replacing the sensor should be easy, and it is for Apple, they just have to pair the new sensor to the phone (or Apple lied about all of that and data can be retrieved from the secure enclave, or it is vulnerable to replays).
Even better, there is a secondary key exchange used for each unlock transaction, utilizing a rolling key in order to mitigate replay attacks. At least, that's what Apple tells us. They also tell us that the fingerprint data is stored in the secure enclave and cannot be read back out which, if true, necessitates that the secure enclave reads a hash from the scanner and makes the decision whether to unlock or allow the transaction. If any of that, including the pairing you mentioned, is true, any part of it at all, there's no reason to brick the phone. A different sensor shouldn't be able to communicate with the phone and should simply not work, while the rest of the device should be allowed to carry along on its merry way.
In fact, unless it is the home button itself making the match decision (which necessitates that either the button stores the hashes, or they can be read from the secure enclave), there is absolutely no security risk from replacing this button.
In short, Apple is lying to us about the security of the system. Either they're lying about the role of the button (which means they're also lying about the ability of data to be retrieved from the secure enclave) and it is making the match decision, they're lying about the secondary key exchange and replay attacks are possible, or they're lying about Error 53 having anything to do with device security.
Falling back to PIN is how I unlock my wife's iPhone 6s Plus when she asks me to change songs or reply to a message on her behalf while she's driving. There's no reason, absolutely none at all, why the Error 53 can't simply be a logged condition that disables the fingerprint reader; Apple should also be able to fix it by pairing the phone and fingerprint scanner.
This would crack me right the hell up. "Yeah, uh... Hi, I run a business where people pay me to call in fake bomb threats. Someone paid me to call you. There may or may not be a fake bomb somewhere in your building. If there is, don't worry, it's fake. Thanks for helping me make $5 off some poor sap, have a nice day."
So every 1500 songs I'm not streaming is a lost sale, then? Then I'm doing the right thing by keeping my Rhapsody playlist small; eventually all the sales I'm stealing should bankrupt them, right?
I'd gladly lay off but you started up again even now
Everything you are referring to was posted before we supposedly made amends and had already been replied to by you.
Your POST HISTORY SHOWS YOU CONSTANTLY COMING IN AFTER I HAVE BEEN IN POSTS TOO
I stood up for you in one post and directly replied to you in another, in this very topic. Aside from that, there was another thread a few days ago where we interacted, and I made one off-the-cuff remark about wishing you'd leave me alone (in a thread where that type of comment was actually quite relevant), which was also made during that little tiff.
My only posts to or about you since our supposed (and clearly meaningless) truce have been directly to you, people posting as you, or people posting attacking me for the conversation we already had, inquiring as to WTF those attacks are all about since we had come to a new understanding and were supposedly past that like a couple of grown adults.
You know what? I no longer have karma to burn to make amends with you. You're dead to me.
When did I bring up statistics, other than pointing out that R is a statistical analysis language? Whichever AC said that, I can assure you it was not me, just as whoever modded both of us down was not me. I think your "disappointment" is misdirected; you're not family and clearly have no interest in being a friend, though, so your disappointment really doesn't mean much to me. Sorry about that.
Woah, woah, cool it, Alexander. What happened to the last couple messages we exchanged last night? Really not making yourself look good here, buddy, coming at me like this after we made amends.
Right and I'd mod myself down, too.. mhm, so sure. I have one account, one single account, a fact which only Slashdot staff will be able to prove or disprove, much like your claim that I have multiple sockpuppet accounts. You're playing yourself for stupid.
my persona can be as nice as the next person's UNTIL I am attacked
And this is why I was trying to point out that my initial comment, months ago, was indeed a joke and not a directed attack. Ya gotta admit, ya jumped in pretty heavy at the onset.
We good?
Cruzan is good stuff, definitely one of my choice rums when I go that route. Getting any "spendier" than that is just for show. My gin of preference is Citadelle; I bought a bottle of Tanqueray #10 at 4x the cost per ounce one night when I wanted to indulge and it's ended up being a show piece, certainly not best of breed.
I miss the winter weather, but I certainly don't miss being able to wear sandals year-round. I envy your snow right now, though.
I've complimented your work in the past, as a matter of fact. I'm sorry if you did not see it. It's not the application that's the problem, but the personality attached to it. If you read my posts on other topics, not related to you, you'll find that I'm quite often the reasonable one in the room. That leads me to wonder if that's really any different here.
Hopefully it wasn't me who drove you to that drink. I'm more of a gin man, myself, but I do enjoy a good rum; might I ask what you're poring tonight?
Slashdot Mirror
supposedly, according to Apple, the secure enclave handles signature verification and authentication for the entire device, taking the CPU out of the equation
Unless Apple is wrong about how their own device works.
Yup, because a sensor that is disabled (power and data pins) when it fails to authenticate itself can totally prod at the rest of the system.
And if Apple's engineering is that weak, they deserve the criticism. If the secure enclave is truly write-only as Apple claims, if communication between the fingerprint reader and the secure enclave is encrypted as Apple claims, if a rolling secondary key is used as Apple claims, if the match decision is made within the secure enclave (as would be necessary if it is write-only)... see where I'm going with this?
The fingerprint scanner no longer working should tell the user that much, no need to brick the phone to do it. And it would be immediate, not weeks or months later when a system update is installed, like Error 53.
Would it not be possible for law enforcement to replace the real digitizer with one that reports "oh yeah, that's the fingerprint I know" whether or not my finger is being used?
According to Apple, who claims that the fingerprint data is irretrievably stored in the secure enclave (which, if you follow the logic, necessitates that the secure enclave make that decision), no. Of course, if replacing the home button is the security issue they're now claiming it is, it appears they're lying about that. Either way, they're lying.
How are you protected? You've unlocked your phone and they've cloned it prior to the repair that bricked it. The bad guys have you data, but you no longer do.
just look at car security devices that are paired to each other like key readers and electronic steering wheel locks.
Yes, look at those indeed. They don't brick the car, you can have it towed to a dealership, get the pairing updated, and drive off. Apple, on the other hand, won't update the pairing unless they also do the repair; therein lies the problem.
If the switch is a modular component, then it can be swapped out for one that will let the bad guy drive my car away, or a signal (perhaps a replay attack) can be passed down the bus.
The first assertion you make here is flat-out wrong, which you seem to realize in your second assertion. The ECU makes the "start/no-start" decision and replacing the ignition switch cannot change that. In the case of a replay attack, the malicious part would need something to replay; that means a valid key would need to be inserted. In order to pull this off, the 'bad guy' would need to break into your car, remove the ignition, transfer the key pattern to his malicious replay-enabled ignition, and install that, all quickly enough to not be seen and without damage so you don't notice; he, then, would have to wait for you to start the car at least once, then would have to break in again to steal the car. All of this could be mitigated by cryptographically pairing the ignition switch to the ECU so the malicious part can't successfully record the exchange between the key and ECU in the first place, and requiring a dealership visit to pair a new ignition or key (this is what they already do); it can be further mitigated by using a secondary key which changes for each transaction, so even if a successful recording is made, a replay is impossible.
And that's precisely what Apple claims to be doing.
Thankfully, Huawei and Google have learned plenty from the past and the Nexus 6P does not fall into the insecure fingerprint implementation trap. Nexus Imprint adopts a very similar approach to Apple’s Secure Element for Touch ID; this hardware partitioning provides the kind of isolation that is required to nullify the exploits that would have been possible with earlier fingerprint implementations such as found on the HTC One Max.
So, not only are you wrong about what the 'other side' does, you're wrong about what it means.
If communication between the sensor and the secure enclave is encrypted (and with a rolling secondary key, which prevents replay attacks) and data cannot be retrieved from the secure enclave, as Apple is telling us, there is no reason to disable anything but the power and data pins for the sensor if it fails to authenticate itself to the secure enclave at boot. Period. Let it be a dumb button if it doesn't authenticate; if you remove power and data lines from the button, you remove any possibility of a security vulnerability.
But, but... but... can't it just keep trying to authenticate until it's successful? Sure, it can, once per reboot (this is why one should disable the power and data pins on failure). A few quadrillion reboots and it'll finally get in.
So they should be able to repair pretty much anything that can be repaired in-house at an Apple Store.
No repairs are done in-house, they do replacements and the ship out (often to those authorized repair shops) for repair.
This. Fingerprint + PIN would be protected ad the PIN is something you know. Password + PIN for when the fingerprint sensor fails, still protected as it's something you know, rather than something you are.
Considering that it wasn't an issue until iOS 9, I'm gonna go ahead and conclude it's entirely done in software. Idiocy or malice I do not know, but I do know it's unnecessary; supposedly, according to Apple, the secure enclave handles signature verification and authentication for the entire device, taking the CPU out of the equation.
But the CPU and sensor are paired up because you don't want to send the sensor data unencrypted across the bus where it's then subject to spoofing attacks.
Wrong. Supposedly, the fingerprint data is stored in the secure enclave and can not be retrieved. The sensor and secure enclave are paired (the secure enclave and CPU likely are, as well), at least according to Apple, and the match decision of made by the secure enclave.
Now that that's been cleared up, there is no reason to brick the device if the sensor fails to authenticate itself; just don't talk to the sensor anymore. Shut down its power and data lines and turn it into a dumb button like it was on the iPhone 5 and earlier; PIN still works.
Supposedly it is, because the fingerprint hashes aren't supposed to be able to be read from the secure enclave once they've been stored. That necessitates that the secure enclave make the match decision. Technically, leaving it at that doesn't allow for easy secure replacement of the sensor; however, we are told that communication between the sensor and secure enclave is encrypted, and that there is a secondary (rolling) key exchange to prevent replay attacks so, yeah... replacing the sensor should be easy, and it is for Apple, they just have to pair the new sensor to the phone (or Apple lied about all of that and data can be retrieved from the secure enclave, or it is vulnerable to replays).
Even better, there is a secondary key exchange used for each unlock transaction, utilizing a rolling key in order to mitigate replay attacks. At least, that's what Apple tells us. They also tell us that the fingerprint data is stored in the secure enclave and cannot be read back out which, if true, necessitates that the secure enclave reads a hash from the scanner and makes the decision whether to unlock or allow the transaction. If any of that, including the pairing you mentioned, is true, any part of it at all, there's no reason to brick the phone. A different sensor shouldn't be able to communicate with the phone and should simply not work, while the rest of the device should be allowed to carry along on its merry way.
In fact, unless it is the home button itself making the match decision (which necessitates that either the button stores the hashes, or they can be read from the secure enclave), there is absolutely no security risk from replacing this button.
In short, Apple is lying to us about the security of the system. Either they're lying about the role of the button (which means they're also lying about the ability of data to be retrieved from the secure enclave) and it is making the match decision, they're lying about the secondary key exchange and replay attacks are possible, or they're lying about Error 53 having anything to do with device security.
Falling back to PIN is how I unlock my wife's iPhone 6s Plus when she asks me to change songs or reply to a message on her behalf while she's driving. There's no reason, absolutely none at all, why the Error 53 can't simply be a logged condition that disables the fingerprint reader; Apple should also be able to fix it by pairing the phone and fingerprint scanner.
This would crack me right the hell up. "Yeah, uh... Hi, I run a business where people pay me to call in fake bomb threats. Someone paid me to call you. There may or may not be a fake bomb somewhere in your building. If there is, don't worry, it's fake. Thanks for helping me make $5 off some poor sap, have a nice day."
I don't think there's much risk in that.
I wasn't gonna go there but... since he's dead to me now... don't you know it?
So every 1500 songs I'm not streaming is a lost sale, then? Then I'm doing the right thing by keeping my Rhapsody playlist small; eventually all the sales I'm stealing should bankrupt them, right?
I'd gladly lay off but you started up again even now
Everything you are referring to was posted before we supposedly made amends and had already been replied to by you.
Your POST HISTORY SHOWS YOU CONSTANTLY COMING IN AFTER I HAVE BEEN IN POSTS TOO
I stood up for you in one post and directly replied to you in another, in this very topic. Aside from that, there was another thread a few days ago where we interacted, and I made one off-the-cuff remark about wishing you'd leave me alone (in a thread where that type of comment was actually quite relevant), which was also made during that little tiff.
My only posts to or about you since our supposed (and clearly meaningless) truce have been directly to you, people posting as you, or people posting attacking me for the conversation we already had, inquiring as to WTF those attacks are all about since we had come to a new understanding and were supposedly past that like a couple of grown adults.
You know what? I no longer have karma to burn to make amends with you. You're dead to me.
When did I bring up statistics, other than pointing out that R is a statistical analysis language? Whichever AC said that, I can assure you it was not me, just as whoever modded both of us down was not me. I think your "disappointment" is misdirected; you're not family and clearly have no interest in being a friend, though, so your disappointment really doesn't mean much to me. Sorry about that.
Woah, woah, cool it, Alexander. What happened to the last couple messages we exchanged last night? Really not making yourself look good here, buddy, coming at me like this after we made amends.
Right and I'd mod myself down, too.. mhm, so sure. I have one account, one single account, a fact which only Slashdot staff will be able to prove or disprove, much like your claim that I have multiple sockpuppet accounts. You're playing yourself for stupid.
my persona can be as nice as the next person's UNTIL I am attacked
And this is why I was trying to point out that my initial comment, months ago, was indeed a joke and not a directed attack. Ya gotta admit, ya jumped in pretty heavy at the onset.
We good?
Cruzan is good stuff, definitely one of my choice rums when I go that route. Getting any "spendier" than that is just for show. My gin of preference is Citadelle; I bought a bottle of Tanqueray #10 at 4x the cost per ounce one night when I wanted to indulge and it's ended up being a show piece, certainly not best of breed.
I miss the winter weather, but I certainly don't miss being able to wear sandals year-round. I envy your snow right now, though.
I've complimented your work in the past, as a matter of fact. I'm sorry if you did not see it. It's not the application that's the problem, but the personality attached to it. If you read my posts on other topics, not related to you, you'll find that I'm quite often the reasonable one in the room. That leads me to wonder if that's really any different here.
Hopefully it wasn't me who drove you to that drink. I'm more of a gin man, myself, but I do enjoy a good rum; might I ask what you're poring tonight?