4 ms·

I think you're the one who misunderstands. Synced Passkeys are, in the Apple world, still stored in a Secure Element; they just are exportable. https://www.sla

by md_ 3y ago

I think you're the one who misunderstands. Synced Passkeys are, in the Apple world, still stored in a Secure Element; they just are exportable. https://www.slashid.dev/blog/passkeys-deepdive/ https://www.slashid.dev/blog/passkeys-deepdive/ describes this fairly clearly. Syncing does certainly open up attacks that are not possible against non-synced credentials, but you're incorrect to say that synced Passkeys are not stored in the Secure Element. At least, that's my understanding. Tell me if I'm wrong!

klausa 3y ago
No, the person you're replying to is right. "Exportable, but in SEP" is a meaningless distinction (if it even exists, I am not convinced that the article isn't confused about things, but I do not have the time or energy to try to refute it). The security benefits on SEP are that the keys _physically_ cannot leave it; if they're "exportable" and available to AP, then their security is necessarily only as good as of Keychain, and whether they're stored in SEP or on disk doesn't really matter if the AP can access them at all.
- md_ 3y ago
  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/web 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.
  - eran- 3y ago
    The iCloud Sync key pair is stored on the device's keychain, not the Secure Enclave (https://support.apple.com/guide/security/secure-keychain-syncing-sec0a319b35f/ https://support.apple.com/guide/security/secure-keychain-syn...)
    - md_ 3y ago
      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.
  - klausa 3y ago
    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.
lapcat 3y ago
The author of that blog post, who is not Apple, appears to be slightly confused. There's a crucial distinction: 1) The key used to encrypt the keychain is stored in the secure enclave. 2) The keychain data itself is not stored in the secure enclave. The secure enclave only stores keys, whereas the keychain holds arbitrary data of arbitrary length. If keychain data were actually stored in the secure enclave, there would be a danger of it running out of space! https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/protecting_keys_with_the_secure_enclave https://developer.apple.com/documentation/security/certifica... "When you protect a private key with the Secure Enclave, you never handle the plain-text key, making it difficult for the key to become compromised. Instead, you instruct the Secure Enclave to create and encode the key, and later to decode and perform operations with it. You receive only the output of these operations, such as encrypted data or a cryptographic signature verification outcome." Here's the kicker: "Can’t encode preexisting keys. You must use the Secure Enclave to create the keys. Not having a mechanism to transfer plain-text key data into or out of the Secure Enclave is fundamental to its security." In other words, nothing ever goes in, and nothing ever comes out. This makes syncing of secure enclave keys impossible. What can be synced are keys that are encrypted and decrypted by the secure enclave. These keys are the aforementioned "output".
- md_ 3y ago
  What I understand the author to be saying is that the SE will unwrap locally stored synced credentials and then encrypt them to the previously-established iCloud sync key. It doesn't really matter if the storage of the actual wrapped keys is in the secure element or on disk, of course--what matters is if the SE exports unencrypted credentials, or if it fails to validate the identity of the key to which it encrypts credentials before exporting. It doesn't seem from that description like it does either, but it's a bit unclear to me from the docs. Do you know?

by md_ 3y ago

klausa 3y ago

No, the person you're replying to is right. "Exportable, but in SEP" is a meaningless distinction (if it even exists, I am not convinced that the article isn't confused about things, but I do not have the time or energy to try to refute it). The security benefits on SEP are that the keys _physically_ cannot leave it; if they're "exportable" and available to AP, then their security is necessarily only as good as of Keychain, and whether they're stored in SEP or on disk doesn't really matter if the AP can access them at all.

md_ 3y ago
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/web 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.
- eran- 3y ago
  The iCloud Sync key pair is stored on the device's keychain, not the Secure Enclave (https://support.apple.com/guide/security/secure-keychain-syncing-sec0a319b35f/ https://support.apple.com/guide/security/secure-keychain-syn...)
  - md_ 3y ago
    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.
- klausa 3y ago
  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.

lapcat 3y ago

The author of that blog post, who is not Apple, appears to be slightly confused. There's a crucial distinction: 1) The key used to encrypt the keychain is stored in the secure enclave. 2) The keychain data itself is not stored in the secure enclave. The secure enclave only stores keys, whereas the keychain holds arbitrary data of arbitrary length. If keychain data were actually stored in the secure enclave, there would be a danger of it running out of space! https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/protecting_keys_with_the_secure_enclave https://developer.apple.com/documentation/security/certifica... "When you protect a private key with the Secure Enclave, you never handle the plain-text key, making it difficult for the key to become compromised. Instead, you instruct the Secure Enclave to create and encode the key, and later to decode and perform operations with it. You receive only the output of these operations, such as encrypted data or a cryptographic signature verification outcome." Here's the kicker: "Can’t encode preexisting keys. You must use the Secure Enclave to create the keys. Not having a mechanism to transfer plain-text key data into or out of the Secure Enclave is fundamental to its security." In other words, nothing ever goes in, and nothing ever comes out. This makes syncing of secure enclave keys impossible. What can be synced are keys that are encrypted and decrypted by the secure enclave. These keys are the aforementioned "output".

md_ 3y ago
What I understand the author to be saying is that the SE will unwrap locally stored synced credentials and then encrypt them to the previously-established iCloud sync key. It doesn't really matter if the storage of the actual wrapped keys is in the secure element or on disk, of course--what matters is if the SE exports unencrypted credentials, or if it fails to validate the identity of the key to which it encrypts credentials before exporting. It doesn't seem from that description like it does either, but it's a bit unclear to me from the docs. Do you know?