Seems more like short sightedness than "petty revenge."
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:
There's a lot of stuff that depends on the secure element - in fact the phone would be quite useless without it.
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.
> There's a lot of stuff that depends on the secure element - in fact the phone would be quite useless without it.
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).
Correct. In fact, a passcode is always required the first time after you reboot your phone. The passcode secures the Secure Element, which contains the fingerprint data used by Touch ID.
The issue is Apple cannot verify a secure touch ID replacement over a compromised touch ID replacement. Without knowing if your replacement is secure the change potentially compromises the security of the whole device.
IMO bricking on touch ID issues is extreme, but maximises the security of the device.
>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.
At the end of the article, it said that affected customers should contact Apple Support. Are you sure they are not offering a hardware fix at that point? It doesn't sound to me like they're just letting people hang.
>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.
There is a failure in the apple stores vs phone support. I went to two Apple stores to try to get my watch band replaced or fixed under warranty and was told by both of them "no way no how" - but phone support had no problem replacing the band.
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.)
Alternative interpretation -- "A custom voided his warranty by installing some rando third-party aftermarket parts, and is furious that it didn't work out."
> The issue is Apple cannot verify a secure touch ID replacement over a compromised touch ID replacement. Without knowing if your replacement is secure the change potentially compromises the security of the whole device.
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.
Does the 911 feature still works on these phones? 911 should work even without a SIM card and without any other authentication, to purposefully disable a phone in this way may have bigger repercussions than just 'security'.
How? TouchID is the less secure authentication than password/PIN anyway (which is shown by the fact that you need to enter PIN/Pass right after boot). How would just disabling TouchID auth be a worse option?
You can do anything you want on the phone without using Touch ID at all. The fingerprint sensor is not a necessary factor in their implementation, while the passcode is.
I can't try because Apple Pay isn't available here yet. According to this support document it works without Touch ID (emphasis mine):
> 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.
A fingerprint, like any piece of data, is handled at the lowest levels as a number. A number with some constraints, but a number.
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.
>By feeding numbers into the scanner instead of fingers, you can accomplish the same effect as feeding random strings into a password box.
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?
> The issue is Apple cannot verify a secure touch ID replacement over a compromised touch ID replacement. Without knowing if your replacement is secure the change potentially compromises the security of the whole device.
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.
That wouldn't really be a good idea. Someone could steal your phone and replace the TouchID hardware. Then this popup comes up and they say, oh yeah this hardware is totally legit! Then they get your data, impersonate you, charge stuff etc.
Fingerprint scanners are useless for security. My fingerprints are everywhete, especially all over my phone. Touch id merely buys time, which can increase security but if they get my fingerprints, make a dummy finger then they need very little time to open my phone. If they are determined they'll do it. If they are not, probably they won't care about the data in my phone.
They have at most 48 hours (or perhaps 24?) and 5 tries to find your fingerprint and unlock the device. TouchID will discard the keys and require a passphrase if it is not used for a while or after the fifth invalid fingerprint attempt. The window of opportunity is not that big. I would not characterize it as useless at all.
In fact, when you first reboot your phone, even contacts cannot be accessed until you authenticate with your passcode to unlock the secure element.
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.
That's true. I meant to say it should disable any hardware that was directly tied to the secure element, such as Touch ID and Apple Pay's NFC chip. I didn't mean to imply all encryption services in iOS should be disabled.
The scenario they're protecting against appears (to me) to be a bad actor changing the hardware. If the Touch ID sensor is bad, and you propose falling back to a PIN, who's to say the digitizer isn't compromised too and is recording touches?
Sounds a bit like a downgrade attack if they didn't fail fast and hard at the earliest opportunity.
I don't think they are protecting against that scenario so much as not accounting for it. I expect Apple's assumption is that they provide all components for their devices. People who install unauthorised third party components can no longer have those devices serviced by Apple — so it no longer matters to Apple whether those devices are compromised, because they aren't really "Apple" devices at that point 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.
If you have a secure enclave within the device, then any hardware which has a direct connection to that secure enclave must be authenticated. It doesn't matter about aftermarket replacements.
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.)
> If you have a secure enclave within the device, then any hardware which has a direct connection to that secure enclave must be authenticated.
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.
If I understand this correctly (not an iphone person), the touch ID sensor is just a fingerprint scanner?
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?
Touch ID is a fingerprint scanner, but the Touch ID system is paired with the "Secure Enclave" in Apple's AX chips.
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.
Basically, yes. The Secure Enclave is hardware isolated from the rest of the chip.
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.
Yeah, there's the source of that quote, 'sub dermal ridge flow angle mapping', which at the time was described as 'how we know it's really your finger', along with supposedly measuring 'micro RF fields' to ensure it was a live finger.
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".
Yes. The OS can only tell if the fingerprint matched or not. The checking is done solely in the secure enclave. Presumably the OS also gets told which fingerprint matched too?
I'm pretty sure there was no direct malice here (except for the usual Apple disregard for 3rd party components), but the security reasoning behind this move is still questionable. The only danger of a compromised Touch ID sensor, is that it could record your fingerprint and let the attackers replay that fingerprint to access all your encryption keys on Secret Enclave.
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.
THE critical security system of your phone has been tampered with. PIN data, TouchID data, crypto data and everything else related to security is on that same bus. You do not detail secure info over that channel.
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