12 ms·

The phone was released with iOS 13 which prominently featured enhancements to USB restricted mode[1] which was supposed to defend against GrayKey/Cellebrite att

• matthewmacleod 7y ago
  I think it’s important to stress that we have essentially no solid information as to whether these attacks are real, and if they are, then the methods they use or the amount of time they take, nor what measures can be used against them. Let’s not sing the requiem for their security team just yet.
• londons_explore 7y ago
  Apple's security team has been given the near impossible task of defending a physical device in the hands of an attacker. I wouldn't blame them for any lack of success. Perhaps instead blame them for suggesting to the user physical security is possible at all.
  • Thorrez 7y ago
    > the near impossible task of defending a physical device in the hands of an attacker. If you assume the device is off and the user chose a strong password, it's pretty easy to defend. You simply encrypt the data with a key which is encrypted with the user's password. If you want to protect devices that are on, or want to protect devices with less than stellar passwords, then it becomes harder.
    • afthonos 7y ago
      “if you assume the device is off”? I suppose if you assume the user never puts data on the device, it also becomes easier.
    • DagAgren 7y ago
      That is not very strong protection - it lets you perform dictionary attacks at high speed. It is often more secure to generate a random, high-entropy key and storing it in secure storage, which is what the iPhone does.
      • Thorrez 7y ago
        If you assume a strong password you don't need to worry about dictionary attacks. There are 2 ways to slow down the attacks: key stretching and secure storage. Key stretching is a good idea. I recommend not relying fully on secure storage, because I've heard of tons of hardware vulnerabilities (side channel attacks, undervoltage, electron microscopes, buggy implementation). I trust math more than a physical object. In fact it seems impossible to me to build fully secure storage, because if someone has a delicate enough measurement tool to measure the atoms inside the storage, the data inside can be extracted. If you store the password (or hashed password) as well as the key in the secure storage, and have it only return the key if the input password is correct, you run the risk of someone finding a bug in the storage to extract the key without the password. Then you're compromised. But you build a system so that the secure storage is no worse than regular crypto. You do the encryption using a combination of the user's password and the output of the secure storage. That way even if the secure storage is fully compromised, the password is still needed.
        • DagAgren 7y ago
          You can't really assume a strong password, because if you have to type in 12 characters, letters and punctuation marks every time you want to look at your phone, you're going to give up on the whole thing pretty quickly. To be usable, phones need to allow relatively weak passwords.
          • Thorrez 7y ago
            I've had a password like that on my (Android) phone for ~7 years and haven't given up. I don't use punctuation though, it's not worth the extra taps to get to the punctuation keyboard for the entropy you gain. I've never had fingerprint or face ID enabled either. 12 characters gives 62 bits of entropy. That's plenty if proper key strengthening is in place. Linus Sebastian says that when his phone got slower to open up, he got happier, because it caused him to use his phone less, cutting out the useless stuff. https://youtu.be/WGZh-xP-q7A?t=305 https://youtu.be/WGZh-xP-q7A?t=305
    • deadbunny 7y ago
      > If you assume the device is off When was the last time a regular person turned their phone off? Not counting reboots or out of battery incidents I'm going to guess not since it was purchased.
  • Dylan16807 7y ago
    It doesn't need to be perfect. The main requirement is that a chip holds on to a secret key, releases it upon getting the correct pin, has a limit on attempts, and is resilient to voltage and timing attacks. That's difficult but not exceptionally difficult. Apple has chosen to run a ton of code inside the secure enclave, and bugs from that are on them.
    • MiroF 7y ago
      > has a limit on attempts This is potentially a quite difficult problem IMO
      • Dylan16807 7y ago
        Is it? Have nonvolatile storage inside the chip, and increment+verify the attempt counter before checking if the supplied PIN is correct. What do you need beyond that?
        • Jamwinner 7y ago
          How do you know when to reset the counter? You dont want invalid attempts incrementing forever...there is your chink in the armor.
          • Hackbraten 7y ago
            What’s wrong with resetting the counter when unlocked successfully?
            • manicdee 7y ago
              What about unintentional passcode attempts such as a phone in a pocket getting butt-dialled?
              • Dylan16807 7y ago
                The interface should be designed so that you can't butt-dial more than a couple attempts. But if that does happen then the system of timeouts will prevent you from using up all the attempts. None of that gets in the way of resetting the counter only when the user succeeds.
  • sjy 7y ago
    Do you really think it's impossible to "defend a physical device" – prevent an attacker from accessing and decrypting the data stored on it? I believe it is possible, that's the promise of hardware security modules. The article is about a mostly secure physical system that Apple undermines by encouraging the use of easily-cracked numeric PINs. I am not sure if the implementations are there yet, but biometric authentication looks like a promising solution to this problem.
    • mcphage 7y ago
      > biometric authentication looks like a promising solution to this problem Yep, and if it gets hacked, then all you need to do is change your fingerprints.
      • acdha 7y ago
        You need to think about this a bit more: biometrics are bad if you pass them over the network where an attacker can replay them but it's different in a local context where they never leave the device. You get a high-entropy key and an attacker who can get both your device and a sufficiently high-quality biometric scan can also simply do things like like you in a room until you unlock the device. That seems like a reasonable compromise.
        • ColanR 7y ago
          > it's different in a local context where they never leave the device Until the next round of FBI tools, where they extract the fingerprints to their database as part of their unlocking process.
          • sjy 7y ago
            I don’t think any of the existing exploits actually involve extracting keys from a hardware security module.
          • acdha 7y ago
            How do they extract fingerprints? All competent biometric implementations store hashes for exactly this reason.
  • close04 7y ago
    I think people don't fully realize the magnitude of such a task. We're not talking about something like consoles where the attack has to meet a higher bar to be viable (be persistent across reboots and upgrades, work over the internet against the provider's infrastructure, etc.). And as usual, the attacker only needs to get it right once and they can afford to wait for months or years to find the exploit on the particular device they have seized.
  • Hamuko 7y ago
    As far as I know, there is actually a pretty easy defense mechanism against this: strong alphanumeric password. The hard part is trying to defend a physical device in the hands of an attacker while using a simple 6-digit passcode.
  • xtracto 7y ago
    Directv won that war years ago.