[Short version: The phone must have a tiny bit of code stored on the hardware to start. That code cannot be encrypted or the computer couldn't use it. The job of that tiny bit of code is to launch the next step ONLY if the next step is validated. Result: The starting code uses hard coded keys to verify the next step is allowed, which also means that if the signing keys were compromised, the next step could be doctored and not what the phone manufacturer intended.] We
should start with a discussion of what a backdoor is and what it isn't.
Wise people don't use the word backdoor in this context because it is
so often misused that you cannot be sure people will understand your
meaning. [what is a backdoor? what is not a backdoor?] You know what's really helpful? Real world examples. Canada got the Blackberry global decryption key. [Military encryption. ATM encryption. Certificate Authorities] Computers
cannot start working unless they are able to load a program into
memory. That program can't be encrypted, so every device which offers
full disk encryption must start off from something that isn't encrypted.
Once it starts, it will ask for your passphrase or check for the
presence of an authentication device you might have plugged in. It will
attempt to use the authentication information you provide to decrypt the
drive encryption key and use that to load everything that is protected
by encryption. The first thing to note is that any
device with protections against guessing passwords incorrectly must do
that with the non-encrypted system that it loads. If it's not encrypted,
it can be read, modified and replaced with something different. Making
it hard to read, modify and replace is what much of smart phone security
is based on. The second thing to note is that the
actual key, the key which is used by the phone to access the encrypted
data, has to be known to the phone but isn't (typically) visible to the
end user. The end user just trusts that the actual key is being kept
safe. Smart phone manufacturers try to keep that key safe by encrypting
it and making decrypting it depend on authentication information, such
as the id built into the chip and a password you type in. Note that
nothing prevents the manufacturer from knowing the key. Anybody who has
the encryption key the phone uses can access the data the phone is
protecting. This means that if Google or Apple were to create a copy of
the key the phone is using before they sell the phone, they could
decrypt the data (so long as the end user doesn't find a way to change
the key.) Example of how Apple tries
to keep the key secure: "When an iOS device is turned on, its
application processor immediately executes code from read-only memory
known as the Boot ROM. This immutable code, known as the hardware root
of trust, is laid down during chip fabrication, and is implicitly
trusted. The Boot ROM code contains the Apple Root CA public key, which
is used to verify that the Low-Level Bootloader (LLB) is signed by Apple
before allowing it to load." Sequence of events (verification needed)
|
|
|