The new home button hardware can't be securely validated, and a future OS update fails on the unexpected condition of invalid Touch ID hardware. I can imagine that this wasn't a prioritised testing scenario, likely not even considered by Apple when developing iOS.
It's a lousy way to fail — the phone should just disable Touch ID and Apple Pay, and anything that relies on the secure co-processor.
But it feels far more like there's an `else` branch sitting in the iOS codebase somewhere where a programmer has written:
//NOTE: This should never, ever happen
//.. code that triggers error 53
In fact, when you first reboot your phone, even contacts cannot be accessed until you authenticate with your passcode to unlock the secure element. Incoming text messages only show the phone number.
You're right, however - a Touch ID sensor that cannot be verified should not brick the phone. Apple should just disable Touch ID and sever any link between the sensor and the secure element.
Disclaimer: I don't own an iPhone with Touch ID.
However, it seems to me that the phone should still work if you logged on with your PIN instead of with TouchID. It should therefore be as useful as most phones that didn't have TouchID in the first place (which happens to be all my Android and iOS smartphones).
If you can't, there's no need to brick the phone...
IMO bricking on touch ID issues is extreme, but maximises the security of the device.
We are all smart people here and there are several ways to have security without bricking expensive hardware.
First, the update can wipe the device instead of bricking it.
Second, Apple can provide an option to replace the fingerprint chip and charge, $150-$200 or whatever it costs for it.
There would be several better solutions that the most profitable company in the world could figure out if they wanted to. It's funny how their particular solution happens to make them even more money through shutting down third party repairs and making people buy new phones.
This is like your home alarm software(made by the home builder) remotely burning down your house and telling you to build a new one because someone may have tampered with home access and could possibly enter your home.
Second, Apple can provide an option to replace the fingerprint chip and charge, $150-$200 or whatever it costs for it.
>When Olmos, who says he has spent thousands of pounds on Apple products over the years, took it to an Apple store in London, staff told him there was nothing they could do, and that his phone was now junk. He had to pay £270 for a replacement and is furious.
I find the stores are somewhat inconsistent in their application of policy. (Particular if the policy isn't well defined ahead of time, as in this case)
(As an aside, the practice of requiring an appointment to talk to a support person or even just drop off a broken computer is maddening.)
The phone would still work perfectly fine and safe if Touch ID would be disabled and input from the sensor wouldn't be trusted.
What are you even talking about?
If the fingerprint scanner is suspicious, just disable it and leave the rest running. And this is in fact what happens, until a software update is installed and then the phone suddenly decides to brick itself completely.
The fact that you need to enter PIN right after boot, just shows that they use "two factor authentication" to make it even more secure.
It doesn't IN ANY WAY show that TouchID is "the less secure authentication" method of the two.
I believe ApplePay requires TouchID.
> To help ensure the security of Apple Pay, you must have a passcode set on your device and, optionally, Touch ID. [...] To send your payment information, you must authenticate using Touch ID or your passcode.
By feeding numbers into the scanner instead of fingers, you can accomplish the same effect as feeding random strings into a password box. Further, it's also possible to take fingerprints through social engineering, or by getting at the database of a company that uses fingerprints as security. Five bucks says someone's already storing a bunch of fingerprint data as plaintext.
Isn't this exactly why they DON'T allow you to use the iPhone with a potentially tampered with HW/TouchID -- e.g. the very feature/issue we're discussing?
I'd argue that fingerprints for security are just silly to begin with.
The correct solution there would be to pop up a warning saying the TouchID hardware has been tampered with, and giving the user an option to validate it.
I think it's totally OK not to accept authentication from an unvalidated device, but a legitimate user should be able to do the validation.
Couldn't they just ask the user? Use the backup password to authenticate.
If it's my device, I want to be the one who chooses what I trust.
I don't have a password on my iPhone. I don't need one, because I don't store any critical data on the phone, or spend any significant time in environments where it's likely to be stolen. And I guess I'm naive enough to assume that no one from the NSA Tailored Operations department is going to sneak into my bedroom at night and install a malicious fingerprint sensor.
So, no, there is absolutely no reason for Apple to brick my entire iPhone if the sensor fails validation. They should act to maintain the level of security chosen by the user... no more, no less.
Sounds a bit like a downgrade attack if they didn't fail fast and hard at the earliest opportunity.
So why not brick the phone out of the box? Even if the finger scanner is original, somebody may have compromised the digitizer anyway.
This botched handling of replaced hardware that hasn't been paired with the Secure Enclave ties into the above. Apple doesn't expect people to replace such hardware through a third-party, so they don't think to engineer their software to fail gracefully when it happens.
Apple is a fairly security conscious company now so security tradeoffs should not be a surprise.
No matter what the motives behind this mechanism were, it was put in place exactly to prevent 3rd party scanners from working.
And if they implemented authentication and didn't even test what happens if it fails, then well... how do they know it works at all?
The entire purpose of the secure enclave is defeated if it trusts any hardware connected to it.
I'm not saying they didn't test what happens when it fails. I'm saying they didn't do user testing on what happens when it fails. I'm sure the engineers tried out the hardware authentication system. They just didn't test the whole scenario once iOS was sitting on the end product.
So yes, it was put in place to stop any hardware that could not be trusted from accessing users' secure data. But no, it was not done to prevent aftermarket replacements.
The only reason I can see Apple caring about aftermarket replacements is because they are often low quality, and cause customers to go back to Apple with unauthorised repairs. (I've witnessed this more than once in an Apple store, someone coming in who had their screen replaced outside Apple and the touch digitiser was failing. Apple just sends them away.)
Consider reading the description of iOS security features linked somewhere in this thread.
Because what you are describing is a disaster, not security. If some off-chip sensor had access to fingerprint data or crypto keys, anybody capable of installing such chip would also be able to simply dump all the data himself in the comfort of his lab.
As a standalone measure, biometrics make a shitty password substitute because you can't change a finger print if it's compromised, so shouldn't the iphone be secured on the premise that the finger print scanner is already compromised, hence losing it should not qualify as a downgrade attack?
Secure Enclave is a separate coprocessor running its own L4-based microkernel. This hardware is directly paired with security-sensitive hardware (Touch ID, Apple Pay NFC chip, etc). It provides all cryptographic operations for data protection key management and maintains the integrity of data protection even if the kernel has been compromised.
So when you stick a third-party Touch ID sensor in an iPhone it's obviously not going to be paired with the secure coprocessor. It doesn't really matter whether biometrics are shitty passwords, the iOS update process realises there is compromised hardware touching the Secure Enclave and fails in the worst possible way for the user.
Apple's own security guide explains it best [1]:
> The Secure Enclave is responsible for processing fingerprint data from the Touch ID sensor, determining if there is a match against registered ngerprints, and then enabling access or purchases on behalf of the user. Communication between the processor and the Touch ID sensor takes place over a serial peripheral interface bus. The processor forwards the data to the Secure Enclave but cannot read it. It’s encrypted and authenticated with a session key that is negotiated using the device’s shared key that is provisioned for the Touch ID sensor and the Secure Enclave. The session key exchange uses AES key wrapping with both sides providing a random key that establishes the session key and uses AES-CCM transport encryption.
Regarding the actual fingerprint storage, it looks like the encryption key is kept in the Secure Enclave and the entire decryption and verification process occurs within the Secure Enclave. However the encrypted data itself may be stored outside the Secure Enclave:
> The raster scan is temporarily stored in encrypted memory within the Secure Enclave while being vectorized for analysis, and then it’s discarded. The analysis utilizes sub-dermal ridge flow angle mapping, which is a lossy process that discards minutia data that would be required to reconstruct the user’s actual fingerprint. The resulting map of nodes is stored without any identity information in an encrypted format that can only be read by the Secure Enclave, and is never sent to Apple or backed up to iCloud or iTunes.
[1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf
Except it could be defeated by a laser printed fingerprint on a piece of paper (initially).
"The Secure Enclave is responsible for processing fingerprint data from the Touch ID sensor, determining if there is a match against registered fingerprints, and then enabling access or purchases on behalf of the user. Communication between the processor and the Touch ID sensor takes place over a serial peripheral interface bus. The processor forwards the data to the Secure Enclave but _cannot_ read it".
That would be a huge vulnerability, if there hadn't been thousands of other ways to record your fingerprint, and while most of them are less accurate than a trojan Touch ID, they're also much easier to pull off.
And at the very worst, if a sophisticated malicious actor got the chance to meddle with your phone, they could just skip the Touch ID sensor altogether and install a stealthy fingerprint digitizer in the touch screen or on the back of the phone.
So in short, Apple's security measure, if my understanding is correct, does absolutely nothing to protect the user.
To keep with the care maker example, in Germany, the car makers used to void the 10 years guarantee on the painting of the car if the regular checks were done by an independent car shop. This was then declared as illegal.
I suppose Apple will soon release an update and declare that this was "a bug".
Image if you have your tires changed by an independent car shop and a month later one of your wheels falls off on the highway. Do you start complaining about it to the car's manufacturer because 'it worked perfectly before'. No you don't.
The repair shop didn't repair it properly, if it was repaired properly the new TouchID sensor would be securely paired with the Secure Enclave and this issue would not occur.
This is more like your Tesla car's keyfob misfunctioning and you get it repaired by a non-Tesla dealer. The dealer could've put in a backdoor to get into the vehicle.
Tesla releases a big new update for their car software and now your Tesla is completely bricked and Tesla refuses to repair it, saying you have to buy a new car.
Is that acceptable?
Apple or other authorized repair shops can still fix phones that have been disabled due to security chain errors.
You are fundamentally misunderstanding the threat model. What is the exact threat that Apple is guarding against? Is it an evil maid attack planting new sensors, switched devices, someone's fingers being cut off? All of these require different mitigations - none of which for a general purpose consumer phone are to brick the device when upgrading.
Anyway, this confirms that I'll stay away from Apple stuff.
That sort of exists now. There are parts, like the throttle control on Volvo's, ABS units on BMW's, etc, where the unit is coded to your vehicle.
You can't, for example, swap an otherwise identical throttle from a junkyard into a Volvo. It puts the ECU into limp mode, and the car is essentially useless.
Now, that's not the result of an over-the-wire firmware update, but that's really the only piece missing. When/If vehicles start regularly updating firmware over the wire, you'll start seeing stuff like this.
We can see that it is clearly nothing to do with 'revenge' or 'retaliation'. The evidence clearly contradicts that.
Apple makes strong promises around security and Touch ID in particular. This is clearly designed to maintain the integrity of that system.
It's certainly a terrible failure mode - the error message should explain what the problem is.
But imputing these bizarre motives just reveals bias on the part of the commenters.
The alternative would be at some point a headline like "compromised Touch ID sends fingerprints to bad actor".
[this was obviously going to be downvoted, but for the record nobody has either made an argument for, or provided evidence for the 'revenge' motivation, while the 'poorly implemented security policy' explanation is clearly supported by the evidence.]
There would be no such headline. Before update to iOS 9, the affected phones functioned normally, but with disabled Touch ID.
And if you have to know why people come up with theories like that - either Apple didn't think what happens to users who already had this hardware replaced or they thought about that. Maybe those who accuse them of malice simply overestimated their competence - after all, they make big claims about high quality, attention to detail and whatnot.
Not to mention that the first part of this comment makes sense and probably expresses well how people feel about this screwup.
This is irrelevant. The problem is that those affected phones could still have had compromised fingerprint sensors.
Apple did the right thing in protecting people from this, but did communicate about it poorly.
The only malice in this situation is on the part of the people accusing apple of being motivated by 'revenge'.
... which wouldn't be used after the phone determines it's an aftermarket part. Equally well the attacker may have installed a malicious piece of brick inside.
> Apple did the right thing in protecting people from this
Sure, they protected users from using phone with replaced home button and disabled fingerprint scanner by bricking the phone completely.
Hard to tell in what proportions malice and/or stupidity were involved in this case, but either way it wasn't "doing the right thing".
However, you have to understand that when I posted this, I knew about cases (including TFA) when the problem had indeed been "rectified" by visiting a store (sorry, couldn't resist ;)) but no case when the device had actually been fixed and data recovered, whether this is technically possible or not.
Given that apple is working on an iCar, it's just a matter of time I presume.
[1] https://www.ifixit.com/Teardown/iPhone+5s+Teardown/17383
But to be honest, it's not like fingerprints are such a hard to obtain secret in the first place.
Then the question is, could the NSA/CIA/etc trick the phone into thinking the repair was valid?
So then, what, if not on boot, show it all the time, with no option to suppress? If you offer a way to suppress it, that will be used by the bad guys.
I'm sure they already did that assuming they don't have better ways.
Apple is in the business of selling (overpriced/overengineered) hardware. Their tactics make that very clear.
The only problem with that is that there is no real competition in mobile phones anymore, it's just a giant duopoly. Sure, you can switch to Google/Android, which as the giant ad company (in other words: personal data hover/mass surveillance company) is just as bad.
My only hope is for Ubuntu to make the right moves soon.
[0] A source: http://www.dailymail.co.uk/sciencetech/article-2709502/Does-...
No, because that never was a fucking thing.
Seriously, this is supposed to be a community of reasonably well-informed tech-oriented people. Step back for a second, take a deep breath, and think before you spread nonsense like this. Jesus.
But please don't comment like this and https://news.ycombinator.com/item?id=11047606 on HN. That just makes the threads worse. Instead, please stay civil even when some people are being silly.
Good lord no. But thank you for the polite response and intention to change. It really is a collective effort.
They completely ignored that a new handset release tends to come in lockstep with a new OS release. This is relevant because it means many, many people are changing the operating characteristics of their existing handsets at the same time - leaving their phone not only not a "known constant", but potentially creating the same results even if a new generation of phone hadn't just appeared at the same time.
Seriously, if you take their graph and replace the labels for each 3g, 3gs, 4, 4s etc, with ios2, 3, 4, 5 .. the data is still accurate, but the take-away assumptions change entirely.
They ignored that geekbench scores show that scores for any given generation stay roughly constant over the phone's lifetime. That's a fantastic set of data that isn't coloured by changing expectations over time.
And they were quite happy to brush off that the samsung numbers showed exactly the same changes over time, as they didn't spike around releases. Completely ignoring that Android has entirely different update strategies (having to wait until your telco 'blesses' the update, etc).
If you look at their graphs, and think of each label as an OS release rather than coinciding with a new handset (which is still accurate), the story it now tells is that ios updates receive much larger adoption in hurry, when compared to adoption of android updates.
Which we already knew. Apple's update strategy is that every compatible handset is able to update "today", whereas android updates are staggered by various levels of support from different mffrs and different providers.
No. Story linked from daily mail (that's not a "source") is more nuanced.
http://www.nytimes.com/2014/07/27/upshot/hold-the-phone-a-bi...
When we try to judge intent we do judge the context. So let's look at the context: people do know that iPhone updates will probably slow their device(even though Apple doesn't tell them that). And there's no way to stop the nagging update notification (aside from jailbreaking).
So let's not be naive. Maybe it's hard to prove at the legal level, but there's a pretty decent chance that this is intentional by Apple.
EDIT: if you upvote, please explain why you think this is wrong.
What's next, people say Apple deliberately destroys batteries after a few years, rather than being a natural consequence of battery chemistry? Apple deliberately makes their screens shatter when dropped?
No, I don't, but I'd like to read more about it. Got a source?
While on the iPhone: Do you use Google search ? Do you use Google maps ?
Well, if you do , there's not much sense in hiding from Google. And if you use Android, you could use tools like cyanogen's "privacy guard" to hide your data from all/most app authors , which i don't think you can do in iOS.
Also , unless they target you specifically, so long that you use an alternative keyboard - i don't think Google on Android collects your key press data - so you can use anonymity apps for special circumstances, But i could be wrong about that. Same goes for encryption keys, unless your targeted.
Hell, there's barely any room for a third manufacturer, let along operating systems http://www.theverge.com/2016/2/3/10894200/android-smartphone...
> No matter how suggestive, he says, the data alone doesn't allow anyone to determine conclusively whether their phone is any slower.
> There are other explanations for why an older model iPhone may slow down, he claims.
> For instance, the latest version of the Apple operating system, iOS, is always tailored to the newest device and may therefore not work as efficiently on older models.
And it is really hard to argue that Google intentionally slows down old Android phones.
The source is available for everyone to study and you can root most devices and install Android versions that don't even use any Google software.
It's just petty revenge because you had to temerity to go to another party other than apple to get your phone repaired and maybe even saved some money in the process. So now, in retaliation we'll destroy your phone in software. I'm sure this will go down well with the various EU courts.