Recovery Key: dumping TLKShares and opening the account vault
By late October the download spine (CloudKit Lock, MMCS, Ford) was no longer the only story. For ADP accounts the deeper gate is cryptographic identity in Octagon. Early October had opened the bottle / iCDP PIN door for trusted devices; when that PIN path is unavailable, the forensic question becomes whether a known Recovery Key can reconstitute the peer that CKKS wrapped keys for—and then unwrap the TLKShares that guard Manatee / PCS / Passwords.
On 24 October 2026 that path crystallized in the lab tooling. The Recovery Key is not “just another password” sent to Apple. Locally you derive an Octagon peer (P-384 signing + encryption material) with HKDF-SHA384 over the RK string and the account altDSID. That peer id is the handle Cuttlefish expects when you ask for recoverable shares.
The important RPC is fetchRecoverableTLKShares (for a given peer).
It can surface the full set of encrypted tlkshare records relevant to recovery—including
shares addressed to Recovery Key peers (names in the tlkshare-…::RK-… family).
With the derived encryption private key you ECIES-unwrap those shares into per-view
TLKs, then OpenVault into CKKS items and the PCS key material needed for
ADP-protected CloudKit zones (backups included) and Keychain-class data.
Practically, the dump also lets you verify whether a candidate Recovery Key belongs to the circle: if unwrap against the RK peer yields nothing, the key is wrong or not present; if views open, you hold the same class of trust a legitimate RK recovery would use—without pretending to be a hardware bottle. That distinction mattered for us: commercial restore roads often stop at ADP; the TLKShare dump is how the research tree crossed into account-level recovery when the Recovery Key was already known.
The next day we opened the repository publicly. This entry is the penultimate beat of that arc: MMCS could fetch ciphertext; Octagon RK + TLKShares decided whether ADP ciphertext was ours to read.
← All notes