Your phone and your laptop

Your phone gets nicked on the tram. Everything is on it: your photos, your chats, your mail, the banking app. And you've protected it with … four digits. Yet the thief doesn't get in, not even if he unsolders the chip and sticks the memory into his own computer. That sounds too good. This chapter explains why it's true anyway, and exactly when it stops being true.

Everything on the disk sits there as ciphertext

Your device's storage is encrypted from beginning to end with AES, the same cipher from chapter 4. That isn't an extra program running along: there's a piece of hardware between the storage chip and the working memory that decrypts every block on reading and encrypts it on writing. You don't notice a thing, and that's the intention.

So where is the key?

Here's the real insight. An AES key is 256 bits: a number out of 2²⁵⁶ possibilities, a number with 78 digits. Your code is four digits. Those two can't possibly be the same thing.

Work it out with me. Four digits from 0 to 9 give 10 × 10 × 10 × 10 possibilities:

10⁴ = 10 000

Ten thousand. Expressed in bits that's log₂(10 000) ≈ 13.3 bits — a little more than 2¹³ = 8192, a little less than 2¹⁴ = 16 384. A computer gets through ten thousand possibilities in less than a second. If your PIN were the key, your device would be open in the blink of an eye.

So the PIN isn't the key. The real key is random and 256 bits long, and it lies in a separate chip that checks the PIN and only then releases it.

That chip also keeps a unique number that was fixed into the silicon at the factory and never comes out of it. The key to your storage is derived from that number and your PIN together. Consequence: unsoldering the storage chip and sticking it in another computer gets you nothing. The unique number stays behind in the device, and without that number there's no key, no matter how many PINs you try.

Why four digits are enough here

In chapter 3 slowness was the weapon: a hash function deliberately turning hundreds of thousands of rounds, so that the attacker takes a fraction of a second per guess instead of a billionth. The same thing happens here, but more radically, and not with calculation but with a clock.

The security chip counts the wrong attempts and simply refuses to answer. Restarting doesn't help — the counter is in the chip, not in the operating system, and after a restart the waiting time even starts running again. These are the real schedules:

Count up what that means. There are ten thousand codes. On an iPhone the thief gets nine of them, and then it's over. On Android he gets nineteen, the last of which costs him nine years. Nineteen out of ten thousand: he has one chance in about 526 if he guesses well, and 1234 or your year of birth are sadly not a good guess.

That is why four digits are enough here and not on a website. On a website the attacker can copy the whole list and guess billions of times a second at home, and the defender has only slowness per guess. Here he can't copy: there's one copy of the key, it sits in one chip, and that chip is counting. Slowness is no longer a delay but a wall.

On the iPhone you can also switch on Erase Data in the passcode settings. The device then wipes itself after ten wrong attempts in a row. Weigh that up against a little brother who likes pressing buttons.

On or off makes a big difference

A device that's completely switched off has the key nowhere. It still has to be worked out from your PIN and the chip number, and until that happens everything in the storage is noise. That's the state before the first unlock: BFU.

But as soon as you've typed in your code once after switching on, the key is in the working memory, and it stays there — even when you lock the screen again. It has to: your phone still has to set off alarms, pull in messages and take calls with a locked screen. That's AFU, after the first unlock, and it's the state your device is in almost all of the time.

Apple makes that explicit with protection classes. The strictest one throws the key away as soon as you lock the screen. The default class for data from third-party apps is called Protected Until First User Authentication and doesn't do that: that key stays in memory until you switch the device off.

In practice: a stolen phone that was switched off is a brick. A stolen phone that was on and had already been unlocked that day is a safe with the key lying on the table inside — still difficult, but this is exactly the difference that forensics companies make their money on. Hence the advice you sometimes hear, which isn't superstition: switch your device fully off if you're really handing it over, or if you're worried about losing it. Restarting is enough — after a restart it's BFU again.

What it doesn't protect against

Disk encryption protects against one thing: someone getting hold of your device while it's locked. Nothing more. If your laptop is open and logged in, everything is simply readable — for you, for the friend who slips in behind it, and for a program you installed by accident. The key is in use at that moment, so everything is neatly decrypted for everybody. The same goes for someone looking over your shoulder, for a screenshot, and for a file you send to a cloud yourself: that leaves decrypted and falls under that cloud's encryption, not your disk's. The key you printed out from chapter 8.1 is just as readable on an unlocked laptop as it is on paper.