0

As far as I'm aware, a locked iOS is considered very safe. No one, who does not know the PIN cannot unlock the phone. While the PIN seems weak on the first glance (4 digits?) it is actually strong, because enough failed attempts = data is wiped. Even law enforcement was known to have troubles when the data they needed was stored on a locked iPhone.

But how does this work and is this an example of security by obscurity?

In my mental model (correct me if I'm wrong) there are the following approaches to securing a system:

  1. Encrypt the system with a strong key, keep the key separate from the system. In this case data cannot be extracted from the system if it remains locked; however, once the system is unlocked, it becomes vulnerable. This is the approach used by schemes such as VeraCrypt. This is not applicable to iPhone since iPhone's PIN is weak. (just a few digits)
  2. Keep the system physically separate from its users ('in the cloud'); only expose a terminal. Do not store data on the terminal and do not do any computations on the terminal; the terminal is only used to send users' commands to the cloud and display data from the cloud to the user. This is how various SaaS services work; but this is not applicable to iPhone again since, AFAIK, data is stored on an iPhone.

The following approach, on the other hand, is, in theory, NOT secure (however it may remain unbroken for surprising long times in practice):

  1. Attempt to secure a system by, essentially, bundling the secrets within the system itself. This is an application of security by obscurity and a violation of Kerckhoffs's principle. The system will only remain secure as long as it is not successfully reverse-engineered. It is very hard to successfully secure a system in this way. For example, many historical and even some contemporary anti-piracy schemes rely on this approach; but as we know, piracy flourished (and flourishes) nonetheless. For example this is why HDCP was broken - keys needed to encrypt data were stored within the devices themselves, so successful reverse-engineering of a device will allow data decryption. This is also how BitLocker works. In BitLocker, data in the hard drive is encrypted using the key stored in the motherboard. But the key can be extracted from the system, see the now-famous attack by 'stacksmashing'. Nonetheless, even though such schemes are theoretically unsound, in practice extreme obfuscation may prove prohibitive to counter-engineering efforts. For example, as far as I'm aware, extreme obfuscation is the only protection employed by the infamous Intel Management Engine. Still, as of know, this protection stands strong as IME has not been yet fully reverse-engineered and, from the POV of the end user, IME remains a black box owned by Intel that has full control over the end user's computer.

I tried Googling how does iPhone's protection work. Couldn't find any definitive answers. This apple.stackexchange.com answer claims: "In iOS8 decryption must be performed on device as it uses a devise specific number (that cannot be extracted from the device) in addition to your pin for encryption; this also prevents Apple from decrypting the device under warrant so you are protected from various three letter organizations serving baseless warrants as Apple has no more advantage in decrypting your device over anyone else." Wait, what? The key needed to decrypt the device is stored in the device itself? How, in that case, can this key not be extracted from the device, as this answer claims?

Unless I'm missing something, this places iPhones squarely in my third bullet. If a device stores the key needed to decrypt itself inside itself, then it employs security by obscurity and violates Kerchkoff's principle. This is precisely the same approach BitLocker employs. The device's only protection against decryption is if its extreme obfuscation levels frustrate reverse-engineering attempts. If so, the device remains secure. Otherwise, the key will be extracted from the device (like stacksmashing managed to do against BitLocker) and the device will be decrypted.

Is my understanding correct?

If not, then how does iPhone manage to secure itself against unauthorized unlocking?

4
  • "The key needed to decrypt the device is stored in the device itself? How, in that case, can this key not be extracted from the device, as this answer claims?" - Such protections are not specific to iPhones, but can also be found in smartcards etc. It's hardware protected and maybe also combined with physical unclonable functions, i.e. bound to the specific instance of the hardware and cannot be cloned. The relevant operations are done in a security chip or dedicated processor enclave, not in normal software. Normal software never gets access to the keys. Commented May 12 at 15:38
  • @SteffenUllrich Wow, hardware security modules are new to me. I thought that every system that contains its own secrets is always security by obscurity. It is difficult for me to imagine how can a key be physically stored and yet it cannot be extracted, not even if the physical module is inspected microscopically. Also how can it be not possible to clone it? As long as we remain in the realm of classical physics, it should be, in principle, possible to recreate the exact structure of any given system?
    – gaazkam
    Commented May 12 at 15:58
  • "Also how can it be not possible to clone it?" - I recommend you read about physically unclonable functions. "... it should be, in principle, possible to recreate the exact structure of any given system?" - if you cannot extract all the information about the structure then you cannot recreate it. This is true for example if the available methods for extracting the structure are too destructive and thus destroy the structure before it could be fully read. Commented May 12 at 16:41
  • Also, security is not about making attacks theoretically impossible, but to make them practically impossible. For this it is enough to make attacks way too expensive (money, time), i.e. the attackers cost should significantly exceed their gain (i.e. the value of what one needs to protect at the time the attack was successful). Commented May 12 at 16:49

1 Answer 1

1

Your understanding is incorrect. Modern iPhones have a separate hardware security module called the Secure Enclave. The Secure Enclave stores keys -- including the file encryption key -- without exposing them to the operating system or even the CPU. Instead, all cryptographic operations are performed with a dedicated AES engine. The Secure Enclave also performs access control checks, so that, for example, a key can only be used after the phone has been unlocked.

This is not security by obscurity. It's hardware-based security. Of course the exact implementation may or may not have vulnerabilities, like every component. But the approach is perfectly valid.

Of course there are alternative approaches, but each of them has its own disadvantages.

  • You could ask the user to generate their own random file encryption key and enter a long sequence of bytes on every boot. That probably won't work very well. It also means the key will be exposed to the operating system, which the iPhone security design specifically avoids.
  • You could use password-based key derivation. Then the strength of the key would depend on the strength of the password, which probably isn't a good idea, since users are notoriously bad a choosing passwords. The password -- and therefore the key -- would also be exposed to the operating system.

So a HSM with PIN protection seems like a pretty reasonable approach.

4
  • Wow, hardware security modules are new to me. I thought that every system that contains its own secrets is always security by obscurity. It is difficult for me to imagine how can a key be physically stored and yet it cannot be extracted, not even if the physical module is inspected microscopically. Also how can it be not possible to clone it? As long as we remain in the realm of classical physics, it should be, in principle, possible to recreate the exact structure of any given system?
    – gaazkam
    Commented May 12 at 15:58
  • In theory, yes. In practice, you're dealing with extremely tightly packaged, tamper-resistant modules that will delete the key if you try to physically open them. There have been successful attacks against HSMs in the past. How far attackers have come with the Secure Enclave -- I don't know. This isn't necessarily publicly available information. But if you take physical attacks into account, then classical PCs are also vulnerable, so this isn't a HSM-specific problem.
    – Ja1024
    Commented May 12 at 16:27
  • But if you take physical attacks into account, then classical PCs are also vulnerable, so this isn't a HSM-specific problem. - yes, however, data stored on them should be safe (impossible to read by the attacker) as long as the key is not stored inside them? I mean a physical attack won't break VeraCrypt, will it?
    – gaazkam
    Commented May 12 at 16:31
  • For VeraCrypt to even encrypt data, you have to boot the operating system, start the application, load the key into RAM etc. All of this can enable an attacker with physical access (or just sufficient privileges) to obtain the key. If you only consider the situation where the PC is completely shut off, the key hasn't been leaked, and the keyfile is inaccessible to the attacker, then, yes, this is theoretically more secure than an HSM. But in practice, the PC isn't always shut off, keys do get leaked (e.g., through an unencrypted swap parition), and keyfiles are sometimes accessible.
    – Ja1024
    Commented May 12 at 17:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .