2

From what little I read about Apple's "Secure enclave", I understand that it's a coprocessor which encrypts/decrypts data based on the user's passcode.

So here's the scenario: I somehow get root access to the main OS. When the user is prompted for their passcode (before buying an app, for example), what's stopping me from sending the passcode I get from the user to my own server, before sending it to the coprocessor?

My main assumption here is that the UI and I/O parts of the workflow are not handled by the coprocessor.

scribu
  • 123
  • 4
  • It is discouraged that users root iOS (or Android) because mischievous applications can do a lot of harm with root access. If you can root the OS remotely, well, there's bigger problems than getting someone's passcode. – h4ckNinja Feb 21 '16 at 23:36

1 Answers1

2

I somehow get root access

That's a pretty big if.

If that were true and subsequently the device had been unlocked at least once then I wouldn't bother intercepting the passcode, according to the iOS security guide:

When a file is opened, its metadata is decrypted with the file system key, revealing the wrapped per-file key and a notation on which class protects it. The per-file key is unwrapped with the class key, then supplied to the hardware AES engine, which decrypts the file as it is read from flash memory.

As root I can presumably open any file I like and read the unencrypted content.

The only limitation of this is that you couldn't learn the passcode at one time, then use it some time in the future to access some data which wasn't originally present. However, I have doubts about whether you could modify the passcode software to intercept the data and send it to you:

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. This is the first step in the chain of trust where each step ensures that the next is signed by Apple. When the LLB finishes its tasks, it verifies and runs the next-stage bootloader, iBoot, which in turn verifies and runs the iOS kernel.

This secure boot chain helps ensure that the lowest levels of software are not tampered with and allows iOS to run only on validated Apple devices.

So you might be able to modify the software temporarily but I doubt you could do it permanently because the system software would be re-verified next boot.

I also strongly suspect that as root you could access some of the derived keys which would render the passcode moot, such as the file system key:

The key that encrypts each file’s metadata, including its class key. This is kept in Effaceable Storage to facilitate fast wipe, rather than confidentiality.

"Rather than confidentiality" sounds to me like it could be read as root and subsequently use it to decrypt the whole file system.

Community
  • 1
thexacre
  • 8,514
  • 3
  • 25
  • 35