Hacker News Reader

Comment by chinathrow | Hacker News Reader

The car industry played the same game a while a go and failed badly.

Allow repairs of the device you OWN with parts you decide and not the manufacturer.

Yes, but if you stored all your bank accounts, credit cards, and private photos in your car, and any repair shop could connect a USB thumb drive and download the contents unencrypted, wouldn't you want a little bit of cryptographic insurance that that wasn't possible?

> Yes, but if you stored all your bank accounts, credit cards

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.

Pretty much all Android devices fit this profile. Even the new encryption-by-default policy announced by Google was only initially applied to Nexus devices, even up until last year. Other vendors may have adopted it more recently but they originally failed to publicize this subtext. The issue apparently was most devices didn't have proper crypto hardware acceleration so it couldn't be applied uniformly across all vendors and only Nexus devices were automatically encrypted post OS install. Hopefully that has changed with newer devices.

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.

This is equivalent to allowing any party in control of your device to circumvent its security by installing a fake fingerprint sensor.

No thank you.

Why not just ask the user if they want to trust the new sensor and authenticate using the password? If attackers have the password you've already lost, so as far as I can tell there's little security risk in allowing that.

Because we already know from long experience that most people don't have the patience or capability to answer security questions.

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).

Couldn't an unscrupulous repair shop just install an event logger in the screen to get the password and skip this whole touchid business? Or even give you back a different phone that just looks like yours and requests your password?

Fundamentally, I feel the real question is who gets to decide who I trust. I want to choose for myself.

Even if someone guesses my PIN, I still don't want them to be able to get a copy of my fingerprint sensor data. Who knows how many multi-factor auth systems will use fingerprints in the future? Stolen fingerprint data could become the next SSN that people use to steal identities.

It seems unlikely that any sensible system would use fingerprint data for security, given how easy it is to spoof. You leave your fingerprints everywhere and can't protect them once you've left the area.

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.

Surely a middle ground is possible? Something along the lines of "Your TouchID sensor has been replaced. If you did not expect this, please take your iPhone to an Apple Store for servicing as your security may be compromised. Otherwise log in with your password to re-enable your device".

The other problem as long as we're continuing with the "user is an idiot" hypothesis is that users don't read error messages. They see a box with a bunch of mumbo-jumbo[1] that's standing in the way of them doing whatever they were doing before the dialog rudely intruded.

[1]:https://pbs.twimg.com/media/CZyYfyEVAAAA6Eo.jpg

I think the issue there is a matter of trust in the hardware too. What if the replacement fingerprint reader has a recorder that sends that fingerprint to the repair shop and the user authorizes it? Now some shady backdoor people have your fingerprint and possibly your pin and any other information that passes through that sensor. It makes sense for Apple to verify the integrity of that hardware chain all the way through when they could potentially be liable for something like that. While they could take the stance that they won't be liable for any phone with a replaced sensor, at that point it's difficult to determine where in that chain the breach happened.

I thought that's what the TechCrunch article said that the OS Update does, isn't it?

By re-enable your device, I meant also re-enabling TouchID (basically saying I trust the new piece of hardware as an auth. method), which this update doesn't do.

Even if it's fake, it should simply transmit fingerprint data to the CPU and not more.

What am I missing here?

The possibility of a skimmer or data modifier.

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)

What threat model do you work under that an attacker would have physical access to the device long enough to replace an entire sensor, but would not have the resources to just take your fingerprints off the physical device?

you mean like taking a photocopy of your finger, licking it, sticking to fingerprint reader and getting a perfect bypass because biometrics is a JOKE and marketing bullet point?

Why the need for a logger/skimmer?

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.

Why make it easier?

It _is_ easy if you have the fingerprint of someone.

That's not broken.

> What am I missing here?

The concept of Secure Enclave, for one.

"The fingerprint sensor is active only when the capacitive steel ring that surrounds the Home button detects the touch of a finger, which triggers the advanced imaging array to scan the finger and send the scan to the Secure Enclave"

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?

If you allow a 3rd party Touch ID sensor to send fingerprint data, you could compromise a powered on iPhone by connecting a malicious Touch ID sensor to it and sending spoofed fingerprints to unlock it.

Isn't the fingerprint data (hash, whatever) stored in the secure enclave? If you're sending spoofed fingerprints, you'd trigger the firmware 5 attempts lockout and need a password.

Not really. Need a replacement ignition key for your VW? You must go to the dealer to get it paired with the immobilizer via live diagnostic link to Germany. And right so IMO.

Reply on news.ycombinator.com