Keychain Melody: Análisis Criptográfico de iCloud en DEF CON 34

Durante la conferencia DEF CON 34, los investigadores de seguridad Alex Radocea y Jaron Bradley (de Jamf Threat Labs) presentaron un análisis detallado sobre los mecanismos de cifrado extremo a extremo (E2EE) de Apple en el ecosistema iCloud. La investigación reveló vulnerabilidades en la arquitectura de gestión de claves locales que permiten comprometer desde contraseñas y Passkeys hasta dispositivos de domótica Matter.

Transcripción Completa de la Conferencia

Moderador: All right, now you can hear me? All right, press button. Welcome to DEF CON, everybody! Who's here for the first time? You can hear, you can hear. All right, very good. Who's here for the first time at DEF CON? All right! Who's been here a few times? All right, well, we have here some new speakers. So, for those of you that are new, you may not know what "Shoot the Noob" is. When somebody is a first-time speaker, we offer them to do a shot on stage. So please put your hands together, we're going to do a shot with our first-time speakers. We got a saying. The saying is: "Don't fuck up." All right, gentlemen, the stage is yours. Alex Radocea: Hello, hi. I'm Alex Radocea. Thanks so much for attending our talk, "Keychain Melody: Grabbing the Keys to the iCloud Kingdom". We've spoken at a couple of other venues for security before, but we were waiting for the right talk with content worth talking about to bring here to you at DEF CON. Jaron Bradley: Yeah, and hello. My name is Jaron Bradley. I work for Jamf. I do detection work for Jamf, and we do all kinds of research around macOS and keeping users safe on Apple devices. Alex and I actually met in the early days of CrowdStrike, working on Apple work as well. Alex kind of worked on engineering the Mac sensor, and I was on the threat hunting and analysis side. So, it's kind of fun to reunite this much later and still be doing this stuff and able to do cool research. Alex Radocea: So, we took a look at iCloud, and Apple claims that all of your iCloud secrets are protected at rest on their servers with end-to-end encryption, which is kind of interesting. And they're also encrypted well on your device and protected from malware with all their security mitigations on the system, making it difficult for things like passkeys to leak out. Roughly six months ago, I was taking a look at something and brought in Jaron for a second look so we could start analyzing the bugs, understand this complex system, and assess the impact better. Jaron Bradley: And one of the reasons it was particularly interesting to me is because info stealers right now, particularly on macOS, are wildly successful. We see a lot of malware day-to-day hitting macOS devices where basically there's this new approach for a lot of malware out there that jumps on the system, tries to exfiltrate everything it can in terms of secrets and your local login Keychain. Because those are so successful, we've always had the question: what if attackers were able, once they've infected a system, to actually get your iCloud secrets? That feels far more dangerous and personal. There's a lot of work stuff being stolen, but when it comes to your personal iCloud, Apple has put a lot of mitigations in place where even if the attacker has compromised your system, they still can't get access to your decrypted iCloud secrets due to new features that Apple started building right around the time info stealers started hitting really hard. So when Alex brought this to me, my question was: in the hands of some of this info stealer malware, how dangerous could this be? And we ran with it and did research around it. To fully grasp the vulnerability itself, we first have to understand a bit about how Apple securely syncs your iCloud Keychain data. We're going to talk a bit about the Apple trust system that has constantly evolved over the years to become very expansive. The details here can be considered high-level because it would take much longer to dive into all details. Our journey begins when we get our first Apple device—let's suppose we buy a brand new Apple computer and walk through what happens when we sign in. You turn on your Mac, sign into that new iCloud account. In the background, on your first cloud-connected device, you are creating what Apple refers to as a "circle of trust". It's a well-thought-out process that allows end-to-end encryption for many iCloud categories. The idea is that secrets in your Keychain and other services should always be encrypted and only readable to devices inside this circle of trust. Taking this a step further, Apple has made it so these secrets are only in memory and cannot be pulled off disk. Alex Radocea: A quick background about the Apple ecosystem: they have a cryptographic coprocessor called the Secure Enclave Processor (SEP). A lot of secrets we're going to talk about don't necessarily live here, but they do interact with it. Passkeys leave these devices, and the Secure Enclave is what protects these secrets when the system is locked or off, doing the work to protect data at rest. On Mac, this first showed up with T1/T2 processors, separate chips on the device, and now they're built into the M-series chips. They run their own operating system called SepOS. One very important thing is that there are AES keys fused into the devices, unique to them, and not even SepOS can read them directly—it can only derive keys or put them in the data path to decrypt data from disk. Jaron Bradley: So when I buy my first Apple device, I create a new iCloud account, log in, and iCloud establishes my circle of trust with that device as the first member. How is that done? The device generates a public and private key pair for iCloud sync, seeded by a random number generator from the Secure Enclave. The private key is never shared with Apple or backed up in plain text to iCloud. This is crucial to the entire operation and allows Apple to claim data cannot be decrypted by them. The public key is added to the circle of trust, representing the new computer's identity. Apple cannot add entities to this circle of trust without an existing trusted device key pair signed by our private key. Alex Radocea: We covered how one device joins, but the point of CloudKit is syncing secrets across devices. Signing in with an iPhone follows a similar process: generating a key pair in RAM. However, the original device gets prompted for a code, going into a cryptographic protocol where the original device creates a voucher for the new device if you prove you know the code. That's how each device gets its own encrypted Keychain that only that device can decrypt. Jaron Bradley: Many concepts from the circle of trust are still active, but it has evolved into a "trusted graph" rather than just a simple circle. The original concept used Off-the-Record (OTR) protocol. The new trusted graph is referred to as Octagon, containing zones for various types of services offered through iCloud. Alex Radocea: One cool thing about this graph is that policies can decide which trusted devices have access to which kinds of secrets (e.g., an Apple TV might not have access to health data). Zones are ruled by a Top-Level Key (TLK), which identity keys can access. TLKs are AES keys—one TLK per zone. These TLKs decrypt another set of keys: the "After First Unlock" (AFU) and "While Unlocked" (WU) keys, applied more on mobile. From those AC keys, you eventually get per-item keys that decrypt the actual content of the secrets. Jaron Bradley: Now let's look at how peers are recorded and managed on macOS, which is where our vulnerability lies. (We are not sharing POC code today due to the info stealer landscape). Much of the peer network management is performed by an XPC process called trustedpeersd (or Trusted Peers Helper). It ensures your Mac stays aware of all other trusted devices in your iCloud. How does it work? trustedpeersd looks up a Mac's Octagon encryption key from its database, fetches TLKs from the keychain-2.db file, and AKS decrypts them into memory. Alex Radocea: Malware in the wild hasn't been seen attacking this yet. Keys to decrypt data aren't readily available; they are behind entitlements (code signing mechanisms required by Apple). There are also anti-debugging protections, and the system is policy-based with strong cryptographic concepts. The vulnerability we're presenting comes down to a way trustedpeersd could be tricked into trusting an attacker's identity temporarily injected into its database—a type of identity swap where the system thinks its identity is now the attacker's identity. Since trustedpeersd has entitlements for Octagon, it can decrypt all secrets. Once the identity is swapped, the system notices missing encryption shares and triggers a "repair process". During this repair, it encrypts all secrets to the attacker's key, writing TLKs to disk encrypted with the attacker's key. This leaves artifacts uploaded to iCloud. Jaron Bradley: This trick works because we hold the private key to decrypt TLK shares after generating the peer identity. Let's look at some demos. The exploit does not require root or TCC permissions. Running octctl (Octagon Control) shows trusted peers. We execute an injection script to place attacker key pairs into the trustedpeersd database, kill trustedpeersd, run ckksctl fetch to trigger automatic repair, copy the keychain database, and extract raw keys using the attacker's private key. This leaves a folder with decrypted zone secrets containing plist files. Passwords (such as passwords.app items) store secrets under v_Data as base64 strings. Decoding these reveals plain-text credentials. Other usable plain-text data includes autofill credit cards, passwords, and Wi-Fi credentials. Beyond passwords, inside the Home zone plist, we find Matter (formerly CHIP) smart home data. Specifically, we extract the fabric's Root Certificate Authority / master signing key. With Swift and CryptoKit, we can load this key to control smart home devices (smart plugs, thermostats, and smart locks). In our testing, using this master key allowed opening a Matter-enabled smart lock directly without passwords. Regarding Passkeys: they store public/private key pairs in v_Data. By extracting the passkey private key and intercepting WebAuthn challenges in the browser console, an attacker can sign the challenge manually and log into services, bypassing biometric (Touch ID / Face ID) checks and 2FA requirements. Alex Radocea: Regarding the Escrow system: Apple uses Hardware Security Modules (HSMs) running SepOS to hold escrow secrets for data recovery. Users authenticate using Secure SRP (zero-knowledge proof) and a device passcode. Escrow entropy derives signing, encryption, and symmetric keys. We uncovered a vulnerability (CVE-2026-28864) where iCloud Backup stored the escrow entropy secret protected only by the Secure Enclave's UID key, omitting passcode/password protection. An attacker with physical access to a backed-up device could recover end-to-end encrypted data without knowing user passcodes. This has since been patched by Apple. For investigation, defenders can monitor `trustedpeersd` database modifications and use `octctl` or `cloudkitctl` tools. Users should maintain unique passwords and avoid reuse.

Post para Blogger: Arquitectura Octagon y Vulnerabilidades en trustedpeersd (CVE-2026-28860 y CVE-2026-28864)

La arquitectura de seguridad de Apple para la sincronización de datos confidenciales en iCloud ha evolucionado desde los esquemas punto a punto sencillos basados en protocolos como OTR hasta una estructura de grafos de confianza conocida como Octagon. En este sistema, la información cifrada punto a punto (E2EE) se fragmenta en zonas administradas por Claves de Nivel Superior (Top-Level Keys o TLK). Estas claves se encargan de resguardar credenciales de acceso, datos biométricos y configuraciones críticas en memoria RAM sin almacenarlas descifradas en el disco del dispositivo.

En el sistema operativo macOS, la gestión de este grafo de confianza recae sobre el demonio trustedpeersd (Trusted Peers Helper). El proceso interactúa con el coprocesador criptográfico Secure Enclave Processor (SEP), garantizando que solo los dispositivos que forman parte de la red autorizada posean las claves privadas necesarias para realizar el descifrado de los datos pertenecientes al Keychain.

Sin embargo, la investigación presentada por Alex Radocea y Jaron Bradley expuso una falla de diseño (catalogada como CVE-2026-28860) en la validación de identidades dentro de trustedpeersd. Mediante la inyección temporal de una clave pública de un atacante dentro de la base de datos local del demonio (sin requerir privilegios de superusuario root ni omisión de permisos TCC), el sistema puede ser manipulado mediante un intercambio de identidad (identity swap). Al detectar la discrepancia en las claves compartidas, el demonio inicia de forma automática un procedimiento de reparación (repair process), re-cifrando las claves TLK del usuario con la clave pública del atacante y escribiéndolas en el disco local.

Este vector de ataque compromete múltiples capas de seguridad de la plataforma:

• Extracción de Credenciales: Permite obtener las contraseñas almacenadas en plano en el atributo v_Data dentro de los archivos de propiedad (plist), así como tarjetas de crédito registradas en el autorrelleno y claves de redes Wi-Fi.
• Bypass de Passkeys y Autenticación Biométrica: Al descifrar el par de claves privada/pública asociado a las Passkeys, el atacante puede interceptar los retos WebAuthn y firmarlos manualmente, eludiendo los controles biométricos de Touch ID/Face ID y los factores dobles de autenticación (2FA).
• Control de Infraestructura Domótica (Matter): En la zona Home, el ataque permite extraer la autoridad de certificación raíz (Root CA) y la clave maestra del tejido de domótica Matter, otorgando control remoto sobre dispositivos IoT, termostatos y cerraduras inteligentes sin interacción del usuario.
• Vulnerabilidad de Escrow (CVE-2026-28864): Adicionalmente, se documentó un fallo en el mecanismo de recuperación mediante módulos HSM (Hardware Security Modules), donde el secreto de entropía de Escrow quedaba protegido únicamente por la clave UID propia del Secure Enclave en las copias de seguridad de iCloud, posibilitando el descifrado completo del respaldo con acceso físico al dispositivo sin requerir el código de desbloqueo.

Apple procedió a corregir la vulnerabilidad mediante parches de seguridad. Para los equipos de respuesta a incidentes y análisis forense, se recomienda la monitorización de eventos que modifiquen la base de datos del demonio trustedpeersd, así como la inspección del grafo mediante herramientas CLI nativas como octctl y cloudkitctl.