8 ms·

OP here. Devious. Cuts off the power source after failed attempts to get around 10 attempts restriction.

makomk 12y ago
Old smart card hacker's trick, surprised Apple didn't defend against it. Of course, it's not enough to delay reporting success or failure until the counter is updated, you've got to make sure there's no side channel that could leak that information early as well.
- knodi123 12y ago
  couldn't you just use a capacitor to give you a few seconds of power after the supply is cut?
  - frankchn 12y ago
    Or just write the attempt count and flush to flash even before checking whether the code is correct? The count can always be updated to zero once it is determined that the code is right.
    - Sanddancer 12y ago
      That would mean a lot of excess writes given the most common use case of the user putting the password in the first time.
      - function_seven 12y ago
        How large is the write? A byte? Or 8 bytes for one 64-bit word? I can't imagine that would impact the user in any way, unless I'm not thinking this through...
        Sanddancer 12y ago
        Flash writes in full blocks, so it would be 4k with most recent flash chips
      - frankchn 12y ago
        From a back of the envelope calculation - given a 10,000 write cycle budget for 16 GB of flash memory and a 512 KB block size (all worst case scenarios), you are looking at 300 million writes before the flash memory starts to fail. I probably unlock my phone 50 times a day (incurring 100 writes under my scheme), and that is negligible in the grand scheme of things.
      - ObviousScience 12y ago
        Let's assume that you're correct, that the most common case is the user putting in the password correctly the first time. Just to get some other numbers, let's assume I sleep 7 hours a day on average, and look at my phone every 5 minutes the rest of the day. Then we're looking at 204 extra writes a day (17 * 12), and ~74.5k extra writes a year, and ~150k writes over the lifetime of the phone. This isn't a negligible change, but seems within the acceptable number of writes for the phone to perform over its lifetime to properly implement a key piece of security.
        Sanddancer 12y ago
        I'd disagree that it's needed. An explicit sync() before returning a notification that the password is invalid would stop this attack as well, and again wouldn't require any additional writes for the most common case of the user entering in the password correctly.
        wang_li 12y ago
        They don't need to write anything. They just need to impose an increasing delay after every failure when the code is being supplied via USB or bluetooth. First failure, wait two seconds, fifth failure wait 30 seconds, eigth failure wait 90 seconds. If they really wanted to write it to flash, they could make it so that the first failure isn't written at all, the second has a 50% chance, the third a 100% chance. Or make it so that if the device has only been running a short period of time, then all failures require a thirty second wait until you can retry. There are plenty of ways to make it impractical without necessarily reducing the lifetime of the device.
      - stordoff 12y ago
        iOS already tracks time since power on IIRC, so if this produces too many writes couldn't you write out to flash first if the phone was last powered on within the last hour (for example)? It wouldn't completely fix the issue, but would vastly increase the time required. That being said, I can't imagine that flushing to flash each time would substantially reduce its lifetime.
        13 12y ago
        > iOS already tracks time since power on IIRC, Records it in photo EXIF data, for some reason.
      - ibmthrowaway218 12y ago
        So: don't write before the first check, write before subsequent checks.
        moe 12y ago
        In this attack there is no subsequent check.
lvillani 12y ago
They also get around the increasing delay enforced after a certain number of failures, to slow down bruteforce attacks.

Old smart card hacker's trick, surprised Apple didn't defend against it. Of course, it's not enough to delay reporting success or failure until the counter is updated, you've got to make sure there's no side channel that could leak that information early as well.

knodi123 12y ago
couldn't you just use a capacitor to give you a few seconds of power after the supply is cut?
- frankchn 12y ago
  Or just write the attempt count and flush to flash even before checking whether the code is correct? The count can always be updated to zero once it is determined that the code is right.
  - Sanddancer 12y ago
    That would mean a lot of excess writes given the most common use case of the user putting the password in the first time.
    - function_seven 12y ago
      How large is the write? A byte? Or 8 bytes for one 64-bit word? I can't imagine that would impact the user in any way, unless I'm not thinking this through...
      - Sanddancer 12y ago
        Flash writes in full blocks, so it would be 4k with most recent flash chips
    - frankchn 12y ago
      From a back of the envelope calculation - given a 10,000 write cycle budget for 16 GB of flash memory and a 512 KB block size (all worst case scenarios), you are looking at 300 million writes before the flash memory starts to fail. I probably unlock my phone 50 times a day (incurring 100 writes under my scheme), and that is negligible in the grand scheme of things.
    - ObviousScience 12y ago
      Let's assume that you're correct, that the most common case is the user putting in the password correctly the first time. Just to get some other numbers, let's assume I sleep 7 hours a day on average, and look at my phone every 5 minutes the rest of the day. Then we're looking at 204 extra writes a day (17 * 12), and ~74.5k extra writes a year, and ~150k writes over the lifetime of the phone. This isn't a negligible change, but seems within the acceptable number of writes for the phone to perform over its lifetime to properly implement a key piece of security.
      - Sanddancer 12y ago
        I'd disagree that it's needed. An explicit sync() before returning a notification that the password is invalid would stop this attack as well, and again wouldn't require any additional writes for the most common case of the user entering in the password correctly.
      - wang_li 12y ago
        They don't need to write anything. They just need to impose an increasing delay after every failure when the code is being supplied via USB or bluetooth. First failure, wait two seconds, fifth failure wait 30 seconds, eigth failure wait 90 seconds. If they really wanted to write it to flash, they could make it so that the first failure isn't written at all, the second has a 50% chance, the third a 100% chance. Or make it so that if the device has only been running a short period of time, then all failures require a thirty second wait until you can retry. There are plenty of ways to make it impractical without necessarily reducing the lifetime of the device.
    - stordoff 12y ago
      iOS already tracks time since power on IIRC, so if this produces too many writes couldn't you write out to flash first if the phone was last powered on within the last hour (for example)? It wouldn't completely fix the issue, but would vastly increase the time required. That being said, I can't imagine that flushing to flash each time would substantially reduce its lifetime.
      - 13 12y ago
        > iOS already tracks time since power on IIRC, Records it in photo EXIF data, for some reason.
    - ibmthrowaway218 12y ago
      So: don't write before the first check, write before subsequent checks.
      - moe 12y ago
        In this attack there is no subsequent check.

lvillani 12y ago

They also get around the increasing delay enforced after a certain number of failures, to slow down bruteforce attacks.