3 ms·

> It would probably not be infeasible to end-to-end encrypt the metadata, in any case (the private key already is) – not sure why Apple isn’t already doing that

by lapcat 2y ago

> It would probably not be infeasible to end-to-end encrypt the metadata, in any case (the private key already is) – not sure why Apple isn’t already doing that. They are. "Keychain items are encrypted using two different AES-256-GCM keys: a table key (metadata) and a per-row key (secret key). Keychain metadata (all attributes other than kSecValue) is encrypted with the metadata key" https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web https://support.apple.com/guide/security/keychain-data-prote... What you download from privacy.apple.com is not your iCloud Keychain data. Apple can't decrypt that.

lxgr 2y ago
Well, that contradicts TFA, which states that > Back to the "Passkeys Information.csv" file. It has two rows for the two passkeys (I don't know why there are two rather than one) and eleven columns. The columns are Created Date and Last Used Date, as I've already noted, as well as Credential ID, Device IP Address, Device Name, Device Serial Number, Device UDID, Domain, Hardware Model, Key ID, and Public Key. That looks a lot like (at least some) metadata to me. Also, the reference you're linking to seems to be talking about device-side data/encryption. It doesn't seem to say anything about what's stored server-side, and using which encryption keys.
- lapcat 2y ago
  > Well, that contradicts TFA I'm the article author. > That looks a lot like (at least some) metadata to me. Yes, it's metadata. > Also, the reference you're linking to seems to be talking about device-side data/encryption. It doesn't seem to say anything about what's stored server-side, and using which encryption keys. iCloud Keychain is end-to-end encrypted. But it's also irrelevant to the linked article. See this comment: https://news.ycombinator.com/item?id=41636398 https://news.ycombinator.com/item?id=41636398
  - lxgr 2y ago
    I'm aware, yet the statements "iCloud Keychaing is fully end-to-end encrypted" and "I was able to download some unencrypted metadata" contradict each other. I think there's actually no contradiction – you are quoting/linking a statement about device-side encryption, but your article is making one about what Apple store on their servers.
    - lapcat 2y ago
      No, you're just confused.
      - lxgr 2y ago
        I really am! I guess you're not interested in a good-faith attempt at clearing up that confusion, though.
        lapcat 2y ago
        I've tried, but you refuse to believe me! iCloud Keychain is end-to-end encrypted. By design, Apple can't decrypt anything, including the metadata. This has been discussed in many places, both by Apple and by others, not just in the one document I linked. The information downloaded in your privacy archive is not your iCloud Keychain data. It's the data related to your apple.com passkey that you use to login to Apple sites and services.
        lxgr 2y ago
        Oh, I was wondering if it was that in the other thread! But in that case, this really is just how passkeys work. The public key is the passkey, and clientId is a "key handle" (sometimes it's the private key encrypted with some root key stored on the hardware authenticator; sometimes it's just a database ID). The device UDID should definitely not be available to relying parties though (WebAuthN is privacy-focused; the only allowable identifier is one that's shared across at least 100 000 devices), so it's confusing that Apple lists yours in their data export. My export is currently pending; I'm curious to see what they're storing for me.

by lapcat 2y ago

lxgr 2y ago

Well, that contradicts TFA, which states that > Back to the "Passkeys Information.csv" file. It has two rows for the two passkeys (I don't know why there are two rather than one) and eleven columns. The columns are Created Date and Last Used Date, as I've already noted, as well as Credential ID, Device IP Address, Device Name, Device Serial Number, Device UDID, Domain, Hardware Model, Key ID, and Public Key. That looks a lot like (at least some) metadata to me. Also, the reference you're linking to seems to be talking about device-side data/encryption. It doesn't seem to say anything about what's stored server-side, and using which encryption keys.

lapcat 2y ago
> Well, that contradicts TFA I'm the article author. > That looks a lot like (at least some) metadata to me. Yes, it's metadata. > Also, the reference you're linking to seems to be talking about device-side data/encryption. It doesn't seem to say anything about what's stored server-side, and using which encryption keys. iCloud Keychain is end-to-end encrypted. But it's also irrelevant to the linked article. See this comment: https://news.ycombinator.com/item?id=41636398 https://news.ycombinator.com/item?id=41636398
- lxgr 2y ago
  I'm aware, yet the statements "iCloud Keychaing is fully end-to-end encrypted" and "I was able to download some unencrypted metadata" contradict each other. I think there's actually no contradiction – you are quoting/linking a statement about device-side encryption, but your article is making one about what Apple store on their servers.
  - lapcat 2y ago
    No, you're just confused.
    - lxgr 2y ago
      I really am! I guess you're not interested in a good-faith attempt at clearing up that confusion, though.
      - lapcat 2y ago
        I've tried, but you refuse to believe me! iCloud Keychain is end-to-end encrypted. By design, Apple can't decrypt anything, including the metadata. This has been discussed in many places, both by Apple and by others, not just in the one document I linked. The information downloaded in your privacy archive is not your iCloud Keychain data. It's the data related to your apple.com passkey that you use to login to Apple sites and services.
        lxgr 2y ago
        Oh, I was wondering if it was that in the other thread! But in that case, this really is just how passkeys work. The public key is the passkey, and clientId is a "key handle" (sometimes it's the private key encrypted with some root key stored on the hardware authenticator; sometimes it's just a database ID). The device UDID should definitely not be available to relying parties though (WebAuthN is privacy-focused; the only allowable identifier is one that's shared across at least 100 000 devices), so it's confusing that Apple lists yours in their data export. My export is currently pending; I'm curious to see what they're storing for me.