If most of the stuff the user cares about is inside the "Insecure World" bubble of the diagram, then this whole business is, like, for shit.
It serves only the platform provider, who can decide which programs may or may not be installed based on whether they are aligned with or against their competitive interests.
This is just plainly false. Passkeys, biometrics, app permissions, and a suite of other user-centric privacy features have clear benefit from strong isolation from an "insecure world" kernel.
Delegating key derivation and/or password validation, combined with secure UI state indication, to a more secure execution environment can be a big win for security, for example.
I could imagine a passkey implementation with some extensions that allow securely presenting what the user is consenting to and how ("enter your payments PIN or password now to confirm a payment of $x to merchant y").
It's of course even better to do that in tamper-proof security coprocessors such as Apple's secure enclave, but TEEs have the big advantage of having access to much more memory and faster processing, which allows doing more complicated things there more easily.
They can also always lean on the secure hardware for actual key management, but handle more complex user interface operations in an environment that's still more secure than the main OS.
Android has supported something just like that years ago with "protected confirmation" [1], but unfortunately it's only available on Pixel phones and hasn't really been picked up by app developers as a result; the situation for Apple is of course very different, so I have some hopes that if they launch something comparable it could actually see some adoption.
Apple is already using the secure enclave for key derivation, PIN/password rate limiting etc. (that’s what it’s for), but my point is that there’s currently a gap in that you can often not really know if you are actually talking to the secure enclave or OS-level malware.
How? The secure enclave doesn't have any trusted input/output capabilities other than the power button double click and biometrics. The PIN isn't entered via these.
There’s a thing which I know very little about personally but have hearsay of its existence where it rips control from XNU and takes over touch input for this
If it's running as their user account then they can see it and remove it. The point of the admin account is to prevent this by obfuscation and permission hijack.
The most likely attack model I can imagine is that a jailbroken phone still won’t be able to violate certain functionality (eg a recording LED remains lit, various supervisor functionality can’t be disabled, etc)
Oh; so the camera LED and camera data path would run a remote attestation protocol with the exclave, and the exclave would make sure the led is on whenever it’s forwarding on data from the camera?
(Though I’m not convinced that will actually work on modern apple devices, where the led is pixels that run through the compositor — I guess the video driver stack and window managers are also exclaves in this world?)
I'm not sure how complex modern display controllers are, but I could imagine a simple priority hardware overlay functionality that an exclave has access to (similar to the dedicated "cursor overlay" functionality some older GPUs had, as far as I understand).
Once you have that, you can take the idea further: Displaying an indicator that confirms that all your keystrokes are going to an exclave validating your password, for example.
The much-hated touch bar actually enabled just that, for Apple Pay payments, as far as I remember: It could display something like "touch to confirm payment of $x" on its own screen in a way that was impossible to manipulate from macOS – now here's an opportunity to bring that level of security back without requiring a dedicated display or taking away people's beloved function keys.
The article mentions the display controller runs an Apple OS so I could see there being a secure way for an exclave to call into it for the onscreen indicators.
I would expect that to mean they're not included in screenshots so I'm curious now whether that's true for the iPhone 16.
It serves only the platform provider, who can decide which programs may or may not be installed based on whether they are aligned with or against their competitive interests.