This seems like the right thing to do - disable the unauthorized Touch ID sensor, but don't brick the phone. The secure enclave is still intact and secure, and if you want Touch ID back, you can get it repaired with authorized parts.
Check reviews and ratings of any third-party store before you get your phone repaired. There are great ones and there are terrible ones, just like with any service business. And if anyone from any store tells you they buy iPhone screens from Apple, or that they do use "genuine OEM parts", now you know--they are lying.
haha no, they either use completely fake screen/glass, or fancier "higher quality" (as in not completely shit) recycled gorilla glass + counterfeit screen combo.
What is worse there are no 100% reliable sources of spare parts and you can never be confident about the next shipment.
We have gotten to the point with our distributors where we order in such large quantities that they know us personally--and they also know we're going to send a screen back if it even has one dead pixel. So they send us their best stuff. We still have a small failure rate, which we mitigate by testing each screen as much as we can before giving it back to the customer and then offering a 1-year warranty for manufacturer defects on the screen as well.
It's the best we can do--no matter what technology you buy, unfortunately, it's never going to be 100% perfect. You buy from the vendors that are the most consistent and you pay a bit more for a higher quality product. And, as a customer, that's why I always recommend you read online reviews before you take your phone or computer to be serviced somewhere. The good places have great reviews because they take care of their customers.
Both Chinese distributors and some less-reputable cell phone repair stores love to advertise these screens as "OEM." However, they are NOT, because the new glass doesn't come from Apple. It can't, because Apple doesn't sell replacement parts. So, while part of the screen (the original LCD) may indeed be "OEM", the entire screen--as a whole--is NOT. And that is why we do not call it "OEM" and I will publicly call BS on other places that do.
Again: OEM replacement screens do not exist unless you go to an Apple Store. Apple does not sell the parts. High-quality replacement screens with Gorilla Glass are pretty much indistinguishable from the original, but they are not 100% OEM and should not be labeled as such.
You can stomp up and down and say OEM parts don't exist, but they do. Not only that, but phones that are bricked, stolen, or maybe even water damaged slightly could have the screen salvaged assuming it wasn't ruined. They do exist.
Will you be lucky to get an OEM screen, probably not, but my comment was to highlight the fact that what you're saying about parts being 3rd party 100% of the time are impossible.
If you get your home button repaired by a third party, now, Touch ID simply won't work. Seems reasonable considering home button issues that would require repair are relatively rare--phones with destroyed home buttons are usually in such bad shape that the owner is just glad to get a working phone back, never mind the Touch ID.
Apple Stores usually won't work on phones with bent frames, severe water damage, etc. anyway--they'll just try to sell you a new (refurbished) phone. Third party repair stores will attempt the repair and can often fix the phone, resulting in a happy customer who gets a cheaper repair and gets to keep the data on their phone.
There actually are AASPs for the iPhone; however the only ones that exist are fairly long-standing and grandfathered in. Apple does not allow for new AASPs. I have a very close friend that works for the lone AASP in Auburn, AL (notable because Tim Cook is an Auburn aluminus).
They can do the repair, but it's not a painless one because it does still require a good bit of back and forth with Apple.
Allow repairs of the device you OWN with parts you decide and not the manufacturer.
I wouldn't be surprised if Apple Pay was the actual reason behind all this stuff.
Malware is bad, but malware which can "authorize" payments is a whole new level of bad and would cost Apple actual money. So they run Pay on a separate CPU whose communications with the fingerprint scanner are encrypted to prevent the main CPU (which relays those communications) from replaying user's fingerprint many times to "authorize" unwanted transactions. Hence the "pairing" of home button to the phone.
Regarding specific hardware tied to a device cryptographically, I'm on the fence about this. This is similar to signing-keys used with kernel modules which is still widely used in Windows.
On HN people have speculated that having a manual 'switch' to toggle on the motherboard for doing firmware updates. So the device can't be tampered with remotely. That seems ideal for that threat model.
But I personally don't see a problem with what Apple is doing here even though it's with physical access. Primarily considering the product is an iPhone which is generally sold as an all-encompassing product/service by Apple. It's not a linux-y customizable device. So having the additional security via hardware locked to the Secure Enclave is a value-add if you're going the proprietary route. Apple's customer service is usually quite good, so that's not a significant barrier. There are other options on the market if you want cheap 3rd-party repairs.
No thank you.
The reality is that an unscrupulous repair shop will just answer yes to the prompt (or tell the user to answer yes).
People clicked "install" when prompted by IE to install an unrestricted ActiveX control because a banner ad wanted them to "punch the monkey". Do you really think they're going to think about the security of a touch sensor?
Now take it one step further and imagine a government spy agency wants to intercept phones and replace parts. (In fact I'm sure it is already happening).
Fundamentally, I feel the real question is who gets to decide who I trust. I want to choose for myself.
Authenticator + smart phone is not ideal but it's still better than fingerprints. It's harder to steal a phone from somebody, while it's almost impossible to prevent the theft of your fingerprints.
What am I missing here?
Ie, I add a logger to your sensor, get all of your data, then make a sensor that translates my fingerprint to look like your fingerprint (or just always sends your fingerprint)
Touch ID has been proven to be vulnerable to fingerprint clones for years.
https://www.youtube.com/watch?v=HM8b8d8kSNQ
Edit: Yes, not broken but also not 100% secure.
The concept of Secure Enclave, for one.
Right? So I still can't see why a 3rd party touch ID sensor can't speak the protocol towards the secure enclave. Can you enlighten me on this?
Edit (rate limited) for answer below: Is your argument still valid if you can already can use a dummy finger to unlock your phone as per various CCC videos demonstrated?
https://www.techdirt.com/articles/20160218/10371233643/yes-b...
If that's not the case, then the whole design of a simple pin combined with a complex device id to form a secure key is not as strong as was thought.
Basically, everyone should now use an alphanumeric password on their phones and not rely on the 10-tries limit or on the exponentially increasing delays.
[1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf (page 5)
What proof is there of this ?
Even reports I've heard from people at the White House believe the newer phones are simply not possible for Apple to compromise.
A possible mitigation against the "FBI attack" (which I don't know if Apple has implemented), while still allowing SEP firmware updates, would be to have a simple routine in ROM that the SEP always runs upon boot (before running the SEP firmware blob) to verify that as hash of the firmware blob matches the one previously recorded by the SEP. If it doesn't, it could either wipe and update the hash, or refuse to boot until the previous blob is restored. When updating the firmware normally, the SEP would simply verify the user enters their pin before updating the hash.
Or simply require pin entry (or wipe) for all DFU firmware updates, which seems like a much safer option.
""" Entering Device Firmware Upgrade (DFU) mode
Restoring a device after it enters DFU mode returns it to known good state with the certainty that only unmodified Apple-signed code is present. DFU mode can be entered manually: First connect the device to a computer using a USB cable, then hold down both the Home and Sleep/Wake buttons. After 8 seconds, release the Sleep/Wake button while continuing to hold down the Home button. Note: Nothing will be displayed on the screen when the device is in DFU mode. If the Apple logo appears, the Sleep/Wake button was held down too long. """
[1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf
The only question is, does the existing firmware blank the store keys before flashing the new update. I didn't see any indication that it does.
Lots of people felt (IMHO with poor understandings of the situation) that it was, and that a modern iPhone would never be "hackable" by the government in this way. That turns out not to be the case, for the obvious reason that Apple needs to be able to ship modified firmware for the enclave, and that modified firmware can always contain modifications to emit the encryption keys in a way that the original security metaphor wouldn't have permitted.
Basically: people are hanging their determination that "the iPhone is secure from government snooping by technological measures" on a completely unattested fantasy design. The real device almost certainly doesn't work like that, and even Apple hasn't claimed that it does.
I'm not sure it's useful to have a battle of hypotheses and assumptions couched in the language of confidence and certainty.
But even on the technical side, my point was stronger: the fact that the enclave firmware was just updated to behave differently without wiping the data that it controls argues very (very!) strongly that the "snoop-proof" feature you believe exists... doesn't.
The fact that the enclave firmware can be seamlessly updated while in an unlocked state is not evidence that the enclave firmware can be seamlessly in a locked state.
edit: the "firmware" update is an iOS update that removes the software limitation. SOFTWARE LIMITATION. On newer iPhones it's hardware (secure enclave).
Yes, you can do an firmware update on an encrypted iPhone. It's not full disk encryption. Only user data is encrypted.
The Secure Enclave (in the iPhone 5S and iPhone 6) has a hardware enforced rate limiter that cannot be overridden by a firmware update.
http://blog.trailofbits.com/2016/02/17/apple-can-comply-with...
The article states:
"Apple can update the SE firmware, it does not require the phone passcode, and it does not wipe user data on update."
But it does not support this statement in any way. In my experience, it does either require the phone passcode, or it wipes the data. Of course, I have no idea where that requirement is implemented.
It would be easy and sensible to have the secure enclave require the passcode for an update to its own firmware, or erase the keys it holds when applying such an update without the passcode. Apple doesn't say they do it from what I can tell, but it would fit with everything else they do, it's pretty easy to do, and I've seen no indication that it doesn't do this.
All we know is that Apple at some point increased the delay. Doesn't mean they can decrease it.
It's pretty well accepted at this point that Apple is capable of complying with the FBI's request. The big question is whether Apple would be capable of complying with a similar request with a newer iPhone that includes a Secure Enclave.
http://blog.trailofbits.com/2016/02/17/apple-can-comply-with...
It's claim that the Secure Enclave is comprimisable is based on Apple releasing a firmware update that "increased delays between passcode attempts". From this the author then assumes that Apple then has the ability to "disable passcode delays and auto erase". There is no evidence for this. And there are plenty of other scenarios like their being a hardware minimum attempt delay, auto erase not being possible or the maximum attempt count implemented in hardware.