Sounds like an easy fix: increment a counter value in flash each time the lock screen is displayed, before a PIN has been entered. If the device is put back to sleep without attempting to enter a PIN, decrement the counter.
ETA: You’re off by an order of magnitude here: “can guess all possible four-digit passwords in 11 hours.” From the source: “each PIN entry takes approximately 40 seconds, meaning that it would take up to ~111 hours to bruteforce a 4 digit PIN.”
You mean I’m supposed to have a PIN on my phone? Huh.
So turn off “simple passcode” and change your code to a 6 digit (hundreds of days to bruteforce) or a 7 digit (more than 12 years) or 8 digit (more than a century) code. The nice thing about using an all-numeric code in an iOS device is that it still presents the same numeric entry onscreen device, and the hacker doesn’t know how many digits your code is.
… or update to at least 8.1.1, released four months ago.
What would happen if the flash is put into write-protected mode (should be one wire on the chip) before the attempted write? I think I saw such trick done with some “secure” USB disk…
Ah, good point. I remember back in my satellite hacking days one company’s IRDs used to be able to detect whether or not you had tampered with the WE pin and would lock its UI down if you had. Apple could do something similar: not even allow PIN attempts if the flash is write-protected.
Then there’s the way of JTAG access to the flash, flipping the bits back and resetting the counter.
…what about some sort of a FPGA/DRAM based flash emulator? The UFS spec makes it fairly doable. All sorts of shenanigans are possible this way, with some added hot-air rework station effort…
And if you’re smart, you can test the top third of all pins in under an hour!
I view my login screen without entering a PIN probably half a dozen times or so without unlocking it for various reasons. This method would greatly increase the risk of me wiping my own phone.
So, they can use an expensive machine to get access to someone who doesn’t give-a-shit’s phone.
Yay, technology!
You aren’t doing much of forensics, are you?
I am curious enough to ask you what the hell that is supposed to mean.
Sometimes it is your job to get into such password-protected enclosures of data. Depending on the level of your funding, a chip-level approach with direct readout of the flash and then reconstruction of the filesystem may not be available to you. Such bruteforcing device then becomes a useful tool.
I took this to be another stupid slap at Apple that insists that the purpose of a feature is other than its actual intended purpose just for the sake of trying to take them down a peg. This happens over and over and seems to have had some real effects on the brand that don’t seem useful or accurate.
I didn’t actually follow the link or anything though so . . .
Why?
If the device is put back to sleep without attempting to enter a PIN, decrement the counter.
Perhaps I wasn’t clear there. I’m saying that every time the lock screen is accessed, we take a counter one step closer towards wiping the device. If you do nothing, and the screen times-out due to inactivity, or if you press a button to manually put the phone back to sleep, the system moves that counter back down, stepping away from a data wipe. In this case, the counter ends up in the same place it started.
But if you enter an incorrect PIN, or if you pull the power while the phone is awake but a correct PIN hasn’t yet been entered, then the counter is left alone, keeping that initial increment in place. So the end result is one step closer to wiping.
The vulnerability exists because you’re currently able to gain information about the validity of a PIN with no penalty, if you’re fast enough. I suggest we start by assuming a penalty, and then only grant a pardon if you walk away without learning anything about the PIN: remove any advantage from jumping out in the middle.
Yeah. I suppose the way to go is to just forget about keeping track in flash, and do the whole PIN-checking/attempt-counting via some secure co-processor with internal memory.
Why is this news? The issue was addressed in iOS 8.1.1, released on November 17th, 2014.
It only counts if you entire an entire guess. And each time a guess it made, if you have “Erase Data” after 10 bad guesses enabled, it takes a SIGNIFICANT amount of time before you can make another guess. The more incorrect guesses, the longer you have to wait to try again.
I’ve seen two people talk past each other before, but you two were in different universes there.
