I don't think the distinction is meaningless, though, as I said, I do agree that exportable keys are more vulnerable than non-exportable.
What I understand the iCloud scheme to guarantee is roughly:
1. The TEE will not export keys except encrypted to the previously-established sync keypair. (IOW, it will only export keys after first encrypting them with the public key of the iCloud-sync keypair.)
2. The iCloud sync keypair will not be divulged by the iCloud server-side HSM except upon presentation of the correct auth credentials (your iCloud password or recovery key).
I think this provides meaningful security beyond keys sitting in plaintext on (FDE-encrypted) disk, namely, that malware running on the device cannot itself simply export the keys from the TEE. It must instead join a new keychain to the iCloud trust circle, as described at https://support.apple.com/en-hk/guide/security/sec0a319b35f/..., and to do this, it must be able to authenticate to iCloud as the user.
That's certainly possible--malware running on the device could phish the user's iCloud password, for example. But it's no longer a zero-user-interaction access to the synced key.
Again, clearly weaker than non-exportable keys, but still stronger than keys sitting in plaintext on disk.
I mean, we're moving goalposts here from "guarantees that SEP makes" to "guarantees that iCloud Keychain makes".
You're right that the items from iCloud Keychain don't just sit in a plaintext on a disk, and that the ceremony to join a keyring is a complex and (until proven otherwise) secure one, but none of that is related in anyway to SEP.
The very existence of iCloud Passwords extension for Chrome on Windows should be a proof of that.
I'm not sure how to relate that to the slashid article, which notes,
> In other words, the private key used to encrypt kSecAttrSynchronizable keys in the Secure Enclave is backed in iCloud. As such, when a new device needs to restore the keychain it can reconstruct the private key and thus decrypt the keypair needed to access all the private keys marked as kSecAttrSynchronizable, which include passkeys.
So presumably the iCloud sync pubkey is in fact available to the TEE to do the necessary encryption before exporting the synced credentials. Where that pubkey is stored only matters if you can trick the TEE into encrypting to some other pubkey, which presumably you can't--the implication of the docs seems to be that it pre-establishes which keys it will trust at iCloud enrollment time.
Is that not the case? I think if the TEE happily encrypts to any pubkey, there's a super obvious bypass here, so I doubt that's how the system works.
What I understand the iCloud scheme to guarantee is roughly:
1. The TEE will not export keys except encrypted to the previously-established sync keypair. (IOW, it will only export keys after first encrypting them with the public key of the iCloud-sync keypair.)
2. The iCloud sync keypair will not be divulged by the iCloud server-side HSM except upon presentation of the correct auth credentials (your iCloud password or recovery key).
I think this provides meaningful security beyond keys sitting in plaintext on (FDE-encrypted) disk, namely, that malware running on the device cannot itself simply export the keys from the TEE. It must instead join a new keychain to the iCloud trust circle, as described at https://support.apple.com/en-hk/guide/security/sec0a319b35f/..., and to do this, it must be able to authenticate to iCloud as the user.
That's certainly possible--malware running on the device could phish the user's iCloud password, for example. But it's no longer a zero-user-interaction access to the synced key.
Again, clearly weaker than non-exportable keys, but still stronger than keys sitting in plaintext on disk.