Hacker News Reader

Comment by knodi123 | Hacker News Reader

couldn't you just use a capacitor to give you a few seconds of power after the supply is cut?

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.

That would mean a lot of excess writes given the most common use case of the user putting the password in the first time.

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

Flash writes in full blocks, so it would be 4k with most recent flash chips

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.

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.

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.

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.

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.

> iOS already tracks time since power on IIRC,

Records it in photo EXIF data, for some reason.

So: don't write before the first check, write before subsequent checks.

In this attack there is no subsequent check.

Reply on news.ycombinator.com