3 ms·

No. Everyone should not back Apple. Let's crack that phone open. We then want Apple to improve their security so that no such request by governments would be p

by exodust 11y ago

No. Everyone should not back Apple. Let's crack that phone open. We then want Apple to improve their security so that no such request by governments would be possible in future. Tighten the security so that not even a special custom version of iOS would make a difference to the self destruct measures in place. Then we wouldn't need to waste any time arguing about it.

marcoperaza 11y ago
I've been trying to stir conversation on this point, to little success unfortunately. The whole affair is pretty damning for the tech industry. The people who should know better are parroting Apple's deceptive claims, and many more are just hopping on the anti-surveillance anti-FBI/NSA bandwagon because it fits their political narrative. Just to be clear, I'm against mandated backdoors in products. I should be allowed to make my product as secure as I want to, even against myself. Yes, that might hinder government search and seizure, but that's the government's problem, not mine. I agree with Apple and most other tech companies on this. But Apple isn't being asked to create a backdoor. The door already exists, and was voluntarily created by Apple. Apple has all of the tools and knowledge in its possession to walk through it. Whether that's the PIN itself (it's not), or the code-signing key and source code needed to disable attack mitigations (without which a 4-digit PIN is worthless), doesn't make a difference. As you observe, they could design the phone such that this attack is not possible. They did not, even though they've been claiming otherwise for years now. All of the arguments in favor of Apple boil down to a general opposition to government search and seizure, worries about damage to Apple's reputation, a claim that code-signing occupies a privileged legal position (akin to attorney-client privilege), or a slippery-slope argument that the government will ask for mandated backdoors on all iPhones next. None of these has a chance in court. I'm more and more convinced that Apple is well aware of how legally wrong it is, and is just doing this to save face over erroneously advertising that their phones were secure even against Apple itself (and therefore any government coercion of Apple). If someone is going to challenge me on this, please answer this two-part question: If Apple had the phone's PIN stored in their database, do you think the government should be able to compel them to hand it over? And why is that any different?
- intrasight 11y ago
  I disagree, and here's why it is different. If Apple had a "thing" and a warrant said "give us this thing", then Apple would be compelled to turn over the thing. But Apple doesn't have this thing (the software to hack their own security). The government is saying "make us this thing", ie asking Apple to execute the warrant - which is unprecedented - it's the governments job to execute the warrant not a private company's.
  - marcoperaza 11y ago
    So if instead, the government asked for Apple's source code, build system, code-signing key, and flashing hardware, would that be okay to you? It's not completely unprecedented to require active assistance from a third-party. There's a Supreme Court case about this very issue, United States vs New York Telephone Co. The FBI wanted New York Telephone to install monitoring hardware on their premises and assist the government in its operation. The district court issued an order to that effect. The company offered to instead give the FBI only information, which the FBI could then use to install and maintain the system themselves. The Supreme Court ultimately ruled in favor of the FBI. The main criteria that people have read out of that case is "unreasonable burden". I don't think that the FBI's request to Apple is an "unreasonable burden", especially since the government will pay for any costs. The biggest burden will be on Apple's reputation, but that is self-inflicted from making claims (honestly or not) that ultimately weren't true. I can't imagine the court allowing Apple to keep its technical assistance from the government.
    - intrasight 11y ago
      Yeah, actually that would be ok with me. Because those are "things". But if there is a legal precedent for demanding services, then I guess my point is mute. I guess Apple could charge one billion dollars per person/hour. That MIGHT be enough to cover their costs.
  - vectorjohn 11y ago
    Yes, Apple does have a "thing". And the thing is the signing certificates. The fact that some work is involved in using the thing makes no difference. Every demand requires some work. The fact that they're being asked to do thing A instead of thing B to get some outcome seems to be a weird place to draw the line. If it took hundreds of man hours to collect and properly separate out data for a single person to hand over to the FBI as evidence, they would be expected to do it. And they will even be compensated for it.
prewett 11y ago
How do you suggest that Apple do that? Somewhere there has to be some code to check if security passed. It is always feasible for Apple to remove/disable the security check in a custom version of iOS.
- dmix 11y ago
  Hardware chips with tamper protection can hold encryption keys which Apple wouldn't be able to modify. It is technically feasible and I'm pretty sure this is why people are saying Secure Enclave protects against this in newer iPhone models. This is also the idea behind TPM chips which are in almost every phone/laptop these days, so consumers couldn't tamper with DRM and other similar crypto systems.
  - prewett 11y ago
    I guess that assumes that the phone's drive is encrypted with the hardware key? Otherwise the software could just ignore the hardware. I find it ironic that this argument in support of TPM, etc. is being made for phones (not necessarily by you), but this same site has vigorously opposed it for PCs, especially Linux.
    - dmix 11y ago
      Android uses TPM chips for their disk encryption scheme. I don't see why Apple wouldn't be doing the same here...
    - marcoperaza 11y ago
      The TPM is basically another processor with a small amount of on-chip storage. It exposes two fundamental operations: seal(plaintext) returns a secret, and and unseal(secret) returns the original plaintext. If you tamper with the device, the internal storage (i.e. the keys it uses to seal and unseal) is wiped. Unseal attempts are rate limited (at the hardware level) to prevent brute force attacks. You can also seal against some other value. So you'd have seal(plaintext, pin) and unseal(secret, pin). Unseal only returns the plaintext if the PIN is the same that was used to seal. This is where it gets really fancy. The TPM has a bunch of built-in registers called PCRs (Platform Configuration Registers). You set a PCR by calling extend(newmeasurement). At boot, the firmware hashes the bootloader and sticks the hash in the first PCR by calling extend(hash). Then the bootloader measures the next boot component (probably a second stage bootloader, or perhaps the BIOS settings), and stores that hash in a PCR, and so forth. The resulting value of each PCR is based on both the measurement passed to extend() and the previous measurements, so the whole chain is verified. The cool thing is that seal() and unseal() can use these PCRs the the same way as, and in addition to, a PIN. Now your disk will only be decrypted if you boot the OS that you used to encrypt it. If you're willing to trust the firmware and OS makers, you don't even need a PIN anymore. The OS's built-in authentication could be enough. Windows PCs tend to have TPMs, but iOS devices have their own hardware encryption solution. I've glossed over and simplified away important details, but that's the gist of it.

by exodust 11y ago

marcoperaza 11y ago

I've been trying to stir conversation on this point, to little success unfortunately. The whole affair is pretty damning for the tech industry. The people who should know better are parroting Apple's deceptive claims, and many more are just hopping on the anti-surveillance anti-FBI/NSA bandwagon because it fits their political narrative. Just to be clear, I'm against mandated backdoors in products. I should be allowed to make my product as secure as I want to, even against myself. Yes, that might hinder government search and seizure, but that's the government's problem, not mine. I agree with Apple and most other tech companies on this. But Apple isn't being asked to create a backdoor. The door already exists, and was voluntarily created by Apple. Apple has all of the tools and knowledge in its possession to walk through it. Whether that's the PIN itself (it's not), or the code-signing key and source code needed to disable attack mitigations (without which a 4-digit PIN is worthless), doesn't make a difference. As you observe, they could design the phone such that this attack is not possible. They did not, even though they've been claiming otherwise for years now. All of the arguments in favor of Apple boil down to a general opposition to government search and seizure, worries about damage to Apple's reputation, a claim that code-signing occupies a privileged legal position (akin to attorney-client privilege), or a slippery-slope argument that the government will ask for mandated backdoors on all iPhones next. None of these has a chance in court. I'm more and more convinced that Apple is well aware of how legally wrong it is, and is just doing this to save face over erroneously advertising that their phones were secure even against Apple itself (and therefore any government coercion of Apple). If someone is going to challenge me on this, please answer this two-part question: If Apple had the phone's PIN stored in their database, do you think the government should be able to compel them to hand it over? And why is that any different?

intrasight 11y ago
I disagree, and here's why it is different. If Apple had a "thing" and a warrant said "give us this thing", then Apple would be compelled to turn over the thing. But Apple doesn't have this thing (the software to hack their own security). The government is saying "make us this thing", ie asking Apple to execute the warrant - which is unprecedented - it's the governments job to execute the warrant not a private company's.
- marcoperaza 11y ago
  So if instead, the government asked for Apple's source code, build system, code-signing key, and flashing hardware, would that be okay to you? It's not completely unprecedented to require active assistance from a third-party. There's a Supreme Court case about this very issue, United States vs New York Telephone Co. The FBI wanted New York Telephone to install monitoring hardware on their premises and assist the government in its operation. The district court issued an order to that effect. The company offered to instead give the FBI only information, which the FBI could then use to install and maintain the system themselves. The Supreme Court ultimately ruled in favor of the FBI. The main criteria that people have read out of that case is "unreasonable burden". I don't think that the FBI's request to Apple is an "unreasonable burden", especially since the government will pay for any costs. The biggest burden will be on Apple's reputation, but that is self-inflicted from making claims (honestly or not) that ultimately weren't true. I can't imagine the court allowing Apple to keep its technical assistance from the government.
  - intrasight 11y ago
    Yeah, actually that would be ok with me. Because those are "things". But if there is a legal precedent for demanding services, then I guess my point is mute. I guess Apple could charge one billion dollars per person/hour. That MIGHT be enough to cover their costs.
- vectorjohn 11y ago
  Yes, Apple does have a "thing". And the thing is the signing certificates. The fact that some work is involved in using the thing makes no difference. Every demand requires some work. The fact that they're being asked to do thing A instead of thing B to get some outcome seems to be a weird place to draw the line. If it took hundreds of man hours to collect and properly separate out data for a single person to hand over to the FBI as evidence, they would be expected to do it. And they will even be compensated for it.

prewett 11y ago

How do you suggest that Apple do that? Somewhere there has to be some code to check if security passed. It is always feasible for Apple to remove/disable the security check in a custom version of iOS.

dmix 11y ago
Hardware chips with tamper protection can hold encryption keys which Apple wouldn't be able to modify. It is technically feasible and I'm pretty sure this is why people are saying Secure Enclave protects against this in newer iPhone models. This is also the idea behind TPM chips which are in almost every phone/laptop these days, so consumers couldn't tamper with DRM and other similar crypto systems.
- prewett 11y ago
  I guess that assumes that the phone's drive is encrypted with the hardware key? Otherwise the software could just ignore the hardware. I find it ironic that this argument in support of TPM, etc. is being made for phones (not necessarily by you), but this same site has vigorously opposed it for PCs, especially Linux.
  - dmix 11y ago
    Android uses TPM chips for their disk encryption scheme. I don't see why Apple wouldn't be doing the same here...
  - marcoperaza 11y ago
    The TPM is basically another processor with a small amount of on-chip storage. It exposes two fundamental operations: seal(plaintext) returns a secret, and and unseal(secret) returns the original plaintext. If you tamper with the device, the internal storage (i.e. the keys it uses to seal and unseal) is wiped. Unseal attempts are rate limited (at the hardware level) to prevent brute force attacks. You can also seal against some other value. So you'd have seal(plaintext, pin) and unseal(secret, pin). Unseal only returns the plaintext if the PIN is the same that was used to seal. This is where it gets really fancy. The TPM has a bunch of built-in registers called PCRs (Platform Configuration Registers). You set a PCR by calling extend(newmeasurement). At boot, the firmware hashes the bootloader and sticks the hash in the first PCR by calling extend(hash). Then the bootloader measures the next boot component (probably a second stage bootloader, or perhaps the BIOS settings), and stores that hash in a PCR, and so forth. The resulting value of each PCR is based on both the measurement passed to extend() and the previous measurements, so the whole chain is verified. The cool thing is that seal() and unseal() can use these PCRs the the same way as, and in addition to, a PIN. Now your disk will only be decrypted if you boot the OS that you used to encrypt it. If you're willing to trust the firmware and OS makers, you don't even need a PIN anymore. The OS's built-in authentication could be enough. Windows PCs tend to have TPMs, but iOS devices have their own hardware encryption solution. I've glossed over and simplified away important details, but that's the gist of it.