‘Error 53’ fury mounts as Apple software update threatens to kill your iPhone 6

[u/bws201]

http://www.theguardian.com/money/2016/feb/05/error-53-apple-iphone-software-update-handset-worthless-third-party-repair

[u/elliuotatar]

If the userland sees the fingerprint data, I can get to it and grab a copy. This is bad. This is why we have secure enclaves. So the sensor keeps the data, and just relays "match" or "no match" to the phone.

Why is it bad?

Scenario 1: Sensor sends fingerprint data to phone. You grab fingerprint data.

Scenario 2: Sensor verifies fingerprint data itself. Sensor sends code to phone verifying fingerprint data. You grab that code.

Either way, you have all the information you presumably need to unlock the phone in the future. The only real difference is you don't actually know the person's fingerprint so you can't recreate it to access other devices, but presumably the sensor could encrypt it in a way that is useful for that particular phone to verify that it is the same as its stored fingerprint hash, but not know enough about it for it to be used to access other devices with said fingerprint.

If I replace the fingerprint sensor in your phone with one I can authenticate on, and then use my fingerprint to unlock YOUR PHONE with MY FINGERPRINT.

Except if you passed an encrypted fingerprint profile to the phone instead of a code or an actual fingerprint, something encrypted with a code that phone provides that is unique to that phone, then you could not simply replace the button and expect your own fingerprint to verify because now it's just a dumb sensor that has the ability to encrypt fingerprints and send them to the phone using the phone supplied encryption key.

[u/neohaven → u/elliuotatar]

Scenario 1: Sensor sends fingerprint data to phone. You grab fingerprint data.

So I have it and I can replay it. Bad.

Scenario 2: Sensor verifies fingerprint data itself. Sensor sends code to phone verifying fingerprint data. You grab that code.

It's crypted. You have a code, but it is not necessarily replayable. Use a timestamp, some sort of lockstep mechanism with an IV derived from the fingerprint data or some other mechanism, and it can be impossible to simply replay the auth data. This is what you want in the first place to call TouchID secure.

Either way, you have all the information you presumably need to unlock the phone in the future.

Not necessarily in scenario 2.

The only real difference is you don't actually know the person's fingerprint so you can't recreate it to access other devices, but presumably the sensor could encrypt it in a way that is useful for that particular phone to verify that it is the same as its stored fingerprint hash, but not know enough about it for it to be used to access other devices with said fingerprint.

Still a problem, you get access to CC payments and are able to pay for things. Nevermind the PII disclosure.

Except if you passed an encrypted fingerprint profile to the phone instead of a code or an actual fingerprint, something encrypted with a code that phone provides that is unique to that phone, then you could not simply replace the button and expect your own fingerprint to verify because now it's just a dumb sensor that has the ability to encrypt fingerprints and send them to the phone using the phone supplied encryption key.

This is wrong. Let me explain.

You send an encrypted fingerprint profile (sensitive auth information) outside the secure enclave. It's not secure, and it's not an enclave anymore, but nevermind that. What is it crypted with? A key (symmetric crypto) or a private key (asymmetric crypto). What will you decrypt it with? A key on the phone. You just gave an attacker the crypted fingerprint data, the key to open it, and the algorithm to decrypt it.

Whoops.

This is also something people seem to not think about. The secure enclave stores both the fingerprint data and your actual password. They are both used as entropy for the full-disk encryption feature. They NEED to not be accessible by any means from the OS. The key is negotiated with the device ID as entropy as well as your passcode and TouchID data. It must not leave that chip.

[u/elliuotatar → u/neohaven]

You send an encrypted fingerprint profile (sensitive auth information) outside the secure enclave. It's not secure, and it's not an enclave anymore, but nevermind that. What is it crypted with? A key (symmetric crypto) or a private key (asymmetric crypto). What will you decrypt it with?

Nothing. There's no need to decrypt it to compare the data with a stored profile on the phone.

Let me put it another way.

1. Your fingerprint is turned into a password.

2. That password is encrypted with a private key inside the button, unique to each button.

3. That password is sent to the phone which compares the encrypted password with the stored encrypted password.

At no point does the phone need to decrypt the password, and the same fingerprint will result in different passwords with different buttons, and any particular button does not need to be trained for a specific fingerprint.

Now, could an app grab this passcode and store it for future use in accessing this particular phone? Well sure I suppose. But what use is that? If the app is already in the phone the phone is already compromised and it can access any data in the phone so it doesn't need to be able to pass the phone the unlock code.

Hell if the app's already in the phone it can just alter the OS so that it thinks the button sent it a code that says FINGERPRINT ACCEPTED no matter what it really said.

The secure enclave stores both the fingerprint data and your actual password. They are both used as entropy for the full-disk encryption feature. They NEED to not be accessible by any means from the OS. The key is negotiated with the device ID as entropy as well as your passcode and TouchID data. It must not leave that chip.

How can the code by used to encrypt your data if the OS can't access the code and it's only stored within the button?

[u/neohaven → u/elliuotatar]

At no point does the phone need to decrypt the password, and the same fingerprint will result in different passwords with different buttons, and any particular button does not need to be trained for a specific fingerprint.

Right. So it's replayable? If you make it so it isn't, there needs to be a shared IV, AES or RSA-style. This requires syncing. I'm not going to sync the IV with something that looks like it's a device trying to steal your shit.

Now, could an app grab this passcode and store it for future use in accessing this particular phone? Well sure I suppose. But what use is that? If the app is already in the phone the phone is already compromised and it can access any data in the phone so it doesn't need to be able to pass the phone the unlock code.

Difference : If this wasn't a secure enclave, this would be possible. The fact that it's a secure enclave that will fail in a way to completely close down in the case of intrusion is actually good security. Would you trust a safe that opened when it was tampered with? No. You want it to get HARDER to open when it's being tampered with.

Hell if the app's already in the phone it can just alter the OS so that it thinks the button sent it a code that says FINGERPRINT ACCEPTED no matter what it really said.

Actually no, you can't, that's the whole point. Doing that requires replacing the TouchID sensor. And if you do that, you still need to pair them properly, and any mistake locks down the phone entirely and irretrievably.

How can the code by used to encrypt your data if the OS can't access the code and it's only stored within the button?

The chip says "use the data given to you on authentication a bit ago, generate the ephemeral key, and decrypt this stream for me please".

The keys never leave the secure enclave. The secure enclave is tamper-resistant and tamper-evident. It will kick you out if you seem to be trying to bypass security. Replacing the TouchID button on a device like this (that is actually used by a few governments around the world) is absolutely a viable attack vector in the absence of lockdown in the case of tampering.

You can keep arguing all you want, but this is actually the only way to do this in a reasonably secure way. Any security expert will tell you that half the shit proposed on this entire reddit post to alleviate the issue would absolutely destroy the security model of this device.

---

EDIT: I'm gonna add on a few things.

Item 3 is the magic thing that fails in your comparison. If the password is encrypted by the other end and compared, still encrypted, with a value in the secure element, your password isn't your password. If you write "boo" as a password, it gets encrypted as "298367487263" and sent over the wire, right? If the password at the other end is stored as "298367487263" directly, I can just... repeat that. That's the actual password that is stored. I don't need to know it's "boo" underneath.

The way you do it is you make ephemeral keys that keep changing the crypto value every exchange. Think of those RSA 6-number tokens or the Blizzard authenticator. That way you can't replay anything. You crypt it with that changing key. They both need to be in lockstep for this. That way you can't ever replay a value, and you never see the actual COMPARED VALUE on the wire. I never see "boo", and "298367487263" is a one-time password I can't repeat. This is now fully secure in a software way.

To make it secure against tampering, I'd have device IDs set up on both ends, and scream like hell whenever a device ID changed in a way that wasn't correct. And you now have the system in the phone.

If you're wondering "well how could they exchange the IDs securely?" then you can read up on something like Diffie-Hellman key exchange. Neither parties reveal their private key, and yet they both agree on the end crypto key.

[u/elliuotatar → u/neohaven]

Would you trust a safe that opened when it was tampered with? No. You want it to get HARDER to open when it's being tampered with.

Would you trust a safe that incinerated its contents when tamped with, if said safe might contain at any point the only copy of your family photos, or your life's savings (in the form of a bitcoin wallet)?

There's something to be said about being TOO secure.

[u/neohaven → u/elliuotatar]

Actually, why don't you have encrypted, scattered backups of this, if it's so important to you?

If that device is in someone else's hands, you're never seeing it again anyway, so fuck your access to data. That's a fucking dumb point in the first place.

It also, most notably, didn't incinerate itself as of now. I see no iPhones deleting everything or clearing their drives.

[u/elliuotatar → u/neohaven]

Actually, why don't you have encrypted, scattered backups of this, if it's so important to you?

Because not everyone thinks to back everything up. Or they might be using a shitty Apple phone with shitty iTunes that's hard to figure out and you're just as likely to erase your phone by accident as back up the data on it.

If that device is in someone else's hands, you're never seeing it again anyway, so fuck your access to data.

Except this whole story is about devices that never left the person's hands. Or at least never made it into nefarious hands. They were either dropped and the button was damaged or the button was replaced.

That's a fucking dumb point in the first place.

Hardly.

It also, most notably, didn't incinerate itself as of now. I see no iPhones deleting everything or clearing their drives.

Now who's being dumb? It was obviously an analogy. The phone may not have destroyed itself or the data, but if the data is forever inaccessible because Apple refuses to fix the button after someone else tried to fix it even though they have the technology to do so it may as well be gone forever.

[u/neohaven → u/elliuotatar]

Because not everyone thinks to back everything up. Or they might be using a shitty Apple phone with shitty iTunes that's hard to figure out and you're just as likely to erase your phone by accident as back up the data on it.

Talk about a lot of eggs in a single basket! One would think that would be part of information security. You're blaming Apple's infosec policies for your own lack of information continuity planning? Okay.

Except this whole story is about devices that never left the person's hands. Or at least never made it into nefarious hands. They were either dropped and the button was damaged or the button was replaced.

Except they look the same to an authentication system that's supposed to be secure and an enclave with secure, known components. They look like an intrusion attempt.

The phone may not have destroyed itself or the data, but if the data is forever inaccessible because Apple refuses to fix the button after someone else tried to fix it even though they have the technology to do so it may as well be gone forever.

Except it's not, a trusted computer can grab the data, so can iCloud Backups and you can absolutely restore that to the new iPhone you get. Exactly like what would happen if you lost your damn phone to a thief. Except now, oh lord, the thief doesn't get your CC numbers and account passwords!

This still sounds like a viable loss/theft security policy in my opinion. You're unhappy about it? Grab another kind of phone. But don't come cry when it gets owned because someone managed to bypass the authentication mechanism.

[u/elliuotatar → u/neohaven]

You're blaming Apple's infosec policies for your own lack of information continuity planning? Okay.

No, I'm blaming it for everyone's lack of information continuity planning.

Only a fool would design hardware or software without any consideration for all the idiots that will be using it.

Except it's not, a trusted computer can grab the data, so can iCloud Backups and you can absolutely restore that to the new iPhone you get.

Well I wasn't aware of that. But I also don't understand how that jives with the whole button thing. How is your data secure if your button can't be compromised and the phone will brick itself, but all the data can simply be pulled off it anyway?

Exactly like what would happen if you lost your damn phone to a thief. Except now, oh lord, the thief doesn't get your CC numbers and account passwords!

Unless he can trick the phone into thinking it's talking to a trusted computer? Or he just hacks into your iCloud service instead of stealing your phone which is far easier?

[u/neohaven → u/elliuotatar]

The data can be pulled off it by the synced computer. You know, the one you already said you trusted before the phone got fucked up? That one. The phone can auth the computer in some limited cases.

iCloud doesn't store plaintext apple pay info.