https://g1a55er.net/feed.xml

TikTok Divestiture Bill Has Passed US House

House Resolution 7521, dubbed the “Protecting Americans from Foreign Adversary Controlled Applications Act,” passed the U.S. House Of Representatives on a bipartisan 352-65 vote today. The current text of the bill as passed can be found here. It’s pretty short and easy-to-read, so I read it, and I have some concerns.

Let’s break down what the proposed law does, where I think it makes some easy mistakes, and how it can be improved. I’m not going to take a stand on whether TikTok should be sold or banned in this post. I will focus on how best to force the sale of TikTok if forcing that sale is the action Congress decides it wants to take.

I am a software developer with a strong interest in tech policy, but no law degree, so you should not take this as a skilled legal analysis, but instead as an analysis of my concerns about how this legal proposal might interact with technology.

How the TikTok Divestiture Bill Works

First, this bill isn’t actually aiming to ban TikTok. It really wants to force ByteDance to sell TikTok to someone else who is not controlled by China. It does that by threatening to make it illegal to distribute the TikTok app to Americans unless ByteDance sells TikTok within 180 days of the law taking effect.

When I pull out my “Congress-to-English” dictionary and read the bill generously, I think what the bill is trying to say is that if ByteDance doesn’t sell TikTok, U.S. based app stores have to take down TikTok for U.S. users and U.S. web hosts must not host the TikTok web app for U.S. users. Unfortunately, when I read the text, that’s not actually what they have said, because the Internet is complicated and it’s hard to write clear rules about it without causing unintended consequences.

Getting into the nitty gritty, the bill defines a category of application of what it calls “foreign adversary controlled applications”. A “foreign adversary controlled application” is defined in Section 2(g)(3) as a:

“website, desktop application, mobile application, or augmented or immersive technology application that is operated, directly or indirectly (including through a parent company, subsidiary, or affiliate), by a covered company that.. is controlled by a foreign adversary; and that is determined by the President to present a significant threat to the national security of the United States…”

It also specifically defines ByteDance Ltd’s operation of TikTok as meeting this definition. It uses the definition of foreign adversary from 10 USC § 4872(d)(2), which includes North Korea, China, Russia, and Iran.

It bans any “entity” (person, company, etc) “within the land or maritime borders of the United States” from:

“(a) Providing services to distribute, maintain, or update such foreign adversary controlled application (including any source code of such application) by means of a marketplace (including an online mobile application store) through which users within the land or maritime borders of the United States may access, maintain, or update such application.

(b) Providing internet hosting services to enable the distribution, maintenance, or updating of such foreign adversary controlled application for users within the land or maritime borders of the United States.”

It enforces this by setting a fine of $5,000 per user per day for violating Part A or $500 per user per day for violating Part B. If you violate either of these prohibitions, the U.S. Attorney General can sue you to get the money and to get a court order to make you stop doing whatever it is you are doing. It provides a specific exemption where the government cannot sue “an individual user of a foreign adversary controlled application”, so it won’t make it illegal to use TikTok, just to distribute/host it.

It does all this threatening to motivate ByteDance to make what it calls a “qualified divesture” of TikTok, or in other words a sale of TikTok to a non-foreign-adversary-controlled company. TikTok would then continue to be allowed to be distributed/hosted/etc by U.S. entities to U.S. users.

This Enforcement Mechanism Kind of Sucks?

There has been previous attempts by U.S. states, most notably in Montana, to ban TikTok that have been struck down by courts as unconstitutional, because they violate the First Amendment. The promoters of this bill are hoping to draft it in such a way that it does not fall victim to that fate. I think they have failed.

The main reason I think they have failed is that their enforcement mechanism - the part of the defines what would be illegal if TikTok refuses to sell - sucks pretty hard. It basically says that if ByteDance fails to sell, then Americans are not allowed to share or facilitate the sharing of software, including source code, written by ByteDance with other Americans. This is a very broad prohibition, a dangerous precedent, and ultimately I think a bigger hammer than is needed to deal with this particular nail.

Classic Constitutional Concerns

First, this would clearly at least raise a constitutional issue based on the Bernstein v. United States precedent that held that software source code was speech protected by the First Amendment.1 As a hypothetical example to demonstrate the parade of horribles, this would seem to preclude a researcher who discovers some mechanism TikTok uses to censor posts about e.g. Tiananmen Square from sharing the source code or binary artifacts to substantiate their claims. After all, couldn’t those artifacts enable the distribution or updating of TikTok? If they could, and the researcher hosted them on the Internet to share them, then the researcher would be providing internet hosting services to enable the distribution or updating of a foreign adversary controlled application. This bill claims to make that illegal. Even if it’s ultimately determined that this bill does not prohibit that sort of thing, it still might require the researcher to get an expensive (thousands of dollars) legal opinion or to be subject to a preemptive takedown by an overzealous host. That is the classic “chilling effect”.

Over-Broadness Concerns

Second, how the bill defines “hosting services” would seem to reach pretty far into the infrastructure of the Internet to effect its prohibitions. This is especially notable, because for a speech-regulation to be constitutional, it must among other things use the “least restrictive means” to achieve its goal. Laws that infringe on more speech rights than strictly necessary to accomplish the government’s “compelling purpose” are not constitutional.

The bill defines hosting services as:

“a service through which storage and computing resources are provided to an individual or organization for the accommodation and maintenance of 1 or more websites or online services, and which may include file hosting, domain name server hosting, cloud hosting, and virtual private server hosting.”

The way I read this, I think it would require Verisign to de-platform the domain “tiktok.com” from the “.com” name servers. After all, the “.com” servers at the very least provide storage resources to maintain the record of what authoritative name servers are responsible for “tiktok.com” domain name in order to maintain the TikTok web app. Also, I think this prohibition has a very broad effect. Part B above prohibits US entities from providing hosting services to anyone who enables the distribution or maintenance of TikTok. I think this effect thus stretches beyond providing DNS services to ByteDance directly, and also prohibits providing DNS services to anyone who enables the distribution of TikTok to US users. So, for example, source code distribution websites or file hosting websites would have to take down TikTok source code or binary files, or else risk getting their domain name revoked.

Finally, a related over-broadness concern I have is whether this bill would effect “peering”, or in other words, whether it would prohibit U.S. Internet Service Providers (ISPs) from routing traffic to a TikTok service hosted abroad. I think it all turns on what “accommodation and maintenance” means. I have not seen this term used before in an Internet law, so I think it is wide open to interpretation. On one hand, I could see a stretch argument about how a U.S. ISP allowing access to a TikTok service hosted abroad would be providing “computer resources” by which the “accommodation or maintenance” of an “online service” that “enables the distribution of the foreign adversary controlled application” is accomplished. On the other hand, to me as a software guy, peering is pretty different from the examples given of file hosting/virtual private server hosting/etc, but I don’t want to read too much into that, because I’m not sure a federal judge would see it that way.

There Is A Better Way

I think the drafters of this bill could easily dodge these First Amendment issues and still achieve their desired effect of threatening to de-platform TikTok from American platforms for American users by taking inspiration from sanctions law. US law already has the concept of the “Specifically Designated Nationals list” (SDN list), which is a list of companies and people that US persons and businesses are prohibited from doing business with. There might be some concern that ByteDance does not currently meet the definition to be listed on the SDN list, but if Congress is already passing a law on this issue, they can specifically clarify that makers of “foreign adversary controlled applications” can be listed on the SDN list. I think that would be much cleaner and easier than setting up some new prohibition mechanism just for TikTok. It would have basically the same desired practical effect: Preventing US businesses from doing business with ByteDance would effectively cut them off from the Apple App Store, Google Play store, US web hosts, cloud providers, and CDNs, and any US domain registrar. It also would prevent them from selling advertisements to US companies, or from making deals with US record companies to include their music libraries in the video editor. It would also not prevent American researchers from publicly sharing any ByteDance-produced source code in their work, or American ISPs from routing traffic to foreign ISPs that later serve TikTok. It would still clearly kill TikTok. It just kills it without threatening a bunch of other probably-constitutionally-protected conduct as a side-effect.

I think this approach is much, much better. Tech platforms are also already very adept at dealing the SDN list. They know what they have to do when a company is listed on it. There is a lot of clarity there. I also think the existence of this alternative approach is a very strong point towards the current bill’s proposed enforcement mechanism not being the least restrictive means to accomplish the compelling government interest, and thus not meeting constitutional muster.

This Bill Might Go Further Than TikTok?

Another concern I have with this bill is the open-ended nature of the ability to designate other apps as “foreign adversary controlled applications”. I think that it’s fine in principle, and probably necessary to have a way to react to future threats without another act of Congress. However, the particular conditions laid down by the bill are probably too lax. For one, despite using the word “controlled”, the bill actually only requires a twenty percent foreign stake to trigger eligibility to be designated. (See Section 2(g)1(b)) It’s not at all uncommon for even American-run social media apps to have large stakes owned by foreign people and companies. For example, Chinese company Tencent did/maybe still does? own a 12 percent stake in Snapchat. A company would not become automatically designated just because it is 20-percent owned by Chinese investors; it would still require action by the President. However, I tend to think that any law that hinges the hope that one person will do the right thing is a bad idea, because hope is not a plan. It’s pretty easy to imagine, for example, a U.S. president threatening to designate a U.S. social media platform as “foreign adversary controlled” if that platform moderates his posts in a way that the President does not approve of.

It’s also notable that I think this definition would cover Telegram, the very popular Russian app whose use is very significant in monitoring ransomware actors and in open-source intelligence of Russian military operations. I’m not going to take a stance here on whether the U.S. should try to force the sale of Telegram, but it is worth thinking about whether that’s the sort of thing we want to empower the government to do, or if we want to further restrict the kinds of national security harm that can merit this kind of action.

U.S. Senate: Cleanup On Aisle HR 7521

Luckily, there is still plenty of time to fix this. It’s unclear when or if this bill will be taken up by the Senate. If they do, I strongly urge them to fix the issues I laid out here. We can all avoid a lot of heartache with just an ounce of careful legislative drafting.

1. This case only made it to the Ninth Circuit Court of Appeals, so this precedent only applies in the Ninth Circuit, but it bolsters the point that the free speech concerns here are credible. ↩

This post is more of a quick PSA. I have been breaking in my new Apple Vision Pro and I was surprised to see that it doesn’t support Lockdown Mode.

There is no option to enable Lockdown Mode at the bottom of the “Privacy & Settings” screen in the Settings app. This is where it normally is on iOS and macOS. There is also not a relevant result when you search for “Lockdown Mode” in Settings.

I also tested that it’s not enabled as some kind of hidden setting that doesn’t show up in the interface. WebGL is disabled when Lockdown Mode is enabled; WebGL works fine on the Apple Vision Pro web browser.

There’s also no website specific option to turn off Lockdown Mode.

The Apple documentation also does not yet mention Lockdown Mode for visionOS at all. It says Lockdown Mode is available in “iOS 16 or later, iPadOS 16 or later, watchOS 10 or later, and macOS Ventura or later.”

So it looks like there really is just no Lockdown Mode for this device right now. Hopefully it comes soon! This thing has just as much attack surface as any other device Apple makes, and we’ve already seen that it needs protection from the same attacks that affect the rest of the Apple ecosystem.

P.S.: While I’m on the subject, I also want to give some kudos to @0xjprx, who found a kernel bug in visionOS on launch day. Was not expecting to see that!

Blissful Ignorance

When I did a fresh install of Windows 11 Home on one of my PCs, I used one of the unofficial, unsupported, yet well known and commonly used tricks to get through the setup process without having to sign in with a Microsoft account. I set up my login to use a PIN1. I assumed this meant that the drive would then be encrypted and protected by Trusted Platform Module (TPM) integrity verification and backed by my PIN.

Et Tu Satya?

This turns out to be wrong.

It turns out that if you skip the Microsoft account sign-in step and only create a “local account”, your data is encrypted but the encryption key is stored on the drive unprotected. This unexpected-to-me behavior is cataloged deep in Microsoft’s own documentation:

[Device] encryption is enabled automatically so that the device is always protected. […] As part of [the out-of-box experience] preparation, device encryption is initialized on the OS drive and fixed data drives on the computer with a clear key that is the equivalent of standard BitLocker suspended state. […] If a device uses only local accounts, then it remains unprotected even though the data is encrypted

Okay, so what exactly does it mean if we are in this state? Well, the documentation above says that it “is the equivalent of standard BitLocker suspended state”, and Microsoft’s BitLocker documentation clarifies what this means:

Suspension of BitLocker does not mean that BitLocker decrypts data on the volume. Instead, suspension makes key used to decrypt the data available to everyone in the clear. New data written to the disk is still encrypted.

So, leaving the key in this “unprotected” or the encryption in means basically leaving the data on the drive unprotected. Any thief or whoever that gets their hands on your drive can get into your data by just decrypting it using the key sitting next to the encrypted data, “unprotected”.

Putting an encryption key on a drive right next to the data it encrypts is about as secure as a safe with the combination written right on it.

Read the Fine Print

I also want to return to the documentation above about the local encryption leaving the key unprotected, because it claims that there should be a warning when this happens:

As part of [the out-of-box experience] preparation, device encryption is initialized on the OS drive and fixed data drives on the computer with a clear key that is the equivalent of standard BitLocker suspended state. In this state, the drive is shown with a warning icon in Windows Explorer. The yellow warning icon is removed after the TPM protector is created and the recovery key is backed up.

For the record, I never noticed a yellow warning icon in my day to day use. That said, I personally find spotting an error indicator on Windows is like playing grandmaster level Where’s Waldo. So for this post, I went back through the process to actively look for it. Nothing shows up on the File Explorer page for the drive, where I would expect it.

Instead, I finally found it buried two levels deep in the Settings app, under “Privacy & security” > “Device encryption”.

It shows up as a yellow bar that says “Sign in to your Microsoft account to finish encrypting this device.” I am not a huge fan of this wording, which might be read to imply that some of your data is already protected, especially when coupled with the fact that the “Device encryption” slider shows as “On”. Really, none of it is protected, because the key is unprotected.

Forewarned is Forearmed

I’m assuming that if you didn’t want to sign into a Microsoft account during setup, you probably don’t want to link your drive encryption key to your Microsoft account. If you are okay with doing that, I assume you can go ahead and tap the button in the warning and sign in to enable encryption.

So, to do that, we have to dive further into the world of unofficial, unsupported solutions with the manage-bde command line tool. Despite being named after the full featured, name brand BitLocker used in Windows 11 Pro, it works just fine on the more restricted, store brand “device encryption” we are stuck with in Windows 11 Home.

To dig in, run manage-bde -status in a shell like Command Prompt or PowerShell:

PS C:\Windows\system32> manage-bde -status
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Disk volumes that can be protected with
BitLocker Drive Encryption:
Volume C: [OS]
[OS Volume]

    Size:                 1337.42 GB
    BitLocker Version:    2.0
    Conversion Status:    Used Space Only Encrypted
    Percentage Encrypted: 100.0%
    Encryption Method:    XTS-AES 128
    Protection Status:    Protection Off
    Lock Status:          Unlocked
    Identification Field: Unknown
    Key Protectors:       None Found

If you get an output like the one above, where it says that the drive is 100% encrypted, but that the “Protection Status” is “Protection Off” and lists no “Key Protectors”, it means you are in this unprotected state where your key is being stored in plaintext right next to your encrypted data. It’s a two-step process to enable key protection from this point.

First, you need to pick a protection scheme and then add a protector with some command like this:

PS C:\Windows\system32> manage-bde c: -protectors -add -tpm
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Key Protectors Added:

    TPM:
      ID: {XXXXX-XXXXX-XXXXX-XXXXX-XXXXXXXXXXX}
      PCR Validation Profile:
        7, 11
        (Uses Secure Boot for integrity validation)

You can find more information about supported key protection schemes here. Unfortunately, my preferred most secure options I tried gave licensing errors, and are thus presumably only available on a more fully equipped version of Windows with the full version of BitLocker.

No matter what other key protectors you add, you should also add a recovery key. This is so that you can still decrypt your data if something goes wrong with your main key protector. You can do this by calling something like manage-bde c: -protectors -add -recoverypassword. You then save the key it gives you in a safe place.2

Second, you need to enable the protection on that specific drive. This is done with another manage-bde command:

PS C:\Windows\system32> manage-bde -on C:
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Volume C: [OS]
[OS Volume]
NOTE: This command did not create any new key protectors. Type
"manage-bde -protectors -add -?" for information on adding more key protectors.
NOTE: Encryption is already complete.
Turned on BitLocker protection by enabling key protectors.

After you complete both steps, you can repeat the status check to confirm it worked. If everything is right, it will look like this:

PS C:\Windows\system32> manage-bde -status
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Disk volumes that can be protected with
BitLocker Drive Encryption:
Volume C: [OS]
[OS Volume]

    Size:                 1337.42 GB
    BitLocker Version:    2.0
    Conversion Status:    Used Space Only Encrypted
    Percentage Encrypted: 100.0%
    Encryption Method:    XTS-AES 128
    Protection Status:    Protection On
    Lock Status:          Unlocked
    Identification Field: Unknown
    Key Protectors:
        TPM

Now my key is stored in my TPM, which will only release it when its integrity checks pass. This is less protection than I would generally prefer, but still much more protection than earlier. It should make it hard enough for a garden variety thief to get their hands on my data if they steal my device. I doubt it would keep out a seriously motivated adversary, though. Unfortunately, as far as I can tell, I would have to pay extra to get full BitLocker for anything offering more protection.

Obligatory Ranting

At the surface level, I don’t think this corner case of systematically lowering the security of users who opt out of using Microsoft accounts was intentional. I think for many normal users having a default that data is not encrypted unless the key is backed up is a reasonable trade-off to avoid catastrophic data loss. Yet, I wonder: why didn’t the setup flow just ask me if I wanted to be responsible for backing up my key myself, or if I wanted to back it up with Microsoft? Apple does!

It’s the obvious answer to that question that pushes me towards my personal conclusion that at a deeper level this outcome was the inevitable product of an earlier deceit and coercion. Microsoft wants you to use use a Microsoft account. They think it makes you more likely to consume Microsoft services. So, they choose not to ask what you want, and instead push you along the path to what they want.

It’s easy to imagine what happens next. Once that decision was made, the standard physics of corporate software development sprung into action. Inevitably, no one prioritizes polishing the setup flow for the small portion of users that manage to jump through the hoops to go down the undesired path. It’s much simpler to silently conflate the choice about key backup with the choice of using a local account. If you use a local account, you don’t backup your keys, so you don’t get disk protection. Simple as.

Also, full BitLocker should really come standard. This kind of confusing, customer-hostile product segmentation was the butt of jokes from Steve Jobs himself 16 years ago. In today’s world of mobile devices, good encryption is table stakes. Charging extra for it feels like keeping seatbelts exclusive to Mercedes Benz. At this point I’m not paying for the upgrade to Pro for BitLocker out of spite, more than anything else.

Summary / TL;DR:

If you set up Windows 11 Home without a Microsoft account, you should double check that drive protection is actually turned on. By default, PCs set up with local accounts remain unprotected. Checking is best done by diving into the command line; turning on the protection if it’s off requires even more Windows command line time. Lucky you! Microsoft discourages setting up PCs with only local accounts, so I doubt they will change this behavior or make fixing this edge case easier.

Change Log

• 1/27/24: Original Post
• 1/27/24: Update with great feedback from @Rairii.

1. This is as far as I can tell, sadly, the highest level of protection available on Windows 11 Home for this device. If I want more, I’ll have to shell out extra bucks to get Windows 11 Pro and its’ full fat BitLocker. I might want more, because as @Rairii points out, TPM protection is pretty weak. ↩

2. Hat tip to @Rairii who pointed this out to me on Mastodon. ↩

TL;DR

It does not look to me like the encryption keys used to secure iCloud data in the Advanced Data Protection regime are changed (i.e. rotated) as needed to provide the promised level of security. I base this claim on my research using Apple’s own tools, open source disclosures, and documentation. I reported this finding to Apple; they closed my report as “expected behavior”, without further clarification.

I disclose my findings to urge another researcher to definitively settle this one way or another. I believe other researchers already have access to tooling to easily do this work.

If my findings are ultimately conclusively proven to represent a security flaw, it would mean that users of iCloud accounts can be permanently compromised by an attacker who steals their encryption keys keys once and then has later access to the cipher texts stored in iCloud. It may also leave users open to attacks where Apple (or an attacker penetrating Apple’s infrastructure) stores the keys that users share with Apple before ADP is enabled, and then later uses those keys to access user content after ADP is enabled. Either of these scenarios ought to break the ADP threat model.

Motivation

This is not the post I originally wanted to write. I wanted to write about how to regain the full security guarantees of iCloud Advanced Data Protection (ADP) after a trusted device compromise. My research question was: “Imagine you’re a journalist and your iPhone (which is logged into your iCloud account) got infected with some nasty malware that can steal anything on it. What do you need to do to trust your iCloud account again?” More specifically, I wanted to know how iCloud’s ADP mode maintains something like forward secrecy after a key compromise.

Unfortunately, my research has led me to doubt the possibility of recovery from such an attack. I submitted a report with my findings to Apple. They responded that my observations were “expected behavior”, and did not elaborate, so I remain unconvinced. I’ll detail what I’ve found, why I suspect it’s unsafe, and finally why I suspect someone else might be in a good position to produce some definitive proof whether this behavior is safe or unsafe1.

Intro to iCloud Advanced Data Protection

Advanced Data Protection (ADP) is Apple’s high-security iCloud mode that ensures that even Apple itself cannot read the data you store in iCloud. It is designed for use by high-risk individuals, like journalists, whistleblowers, political activists, etc. Apple’s documentation describes that it works like this:

• Even under normal security (with ADP off), the vast majority of the content stored in iCloud is encrypted. [See: Page 113 of the Platform Security Guide PDF linked above]
• The keys for this encryption are documented to be maintained in a tree hierarchy, rooted in a single key per CloudKit “service” (i.e. Photos/iCloud Drive/etc.), called the service key in documentation. [Page 114]
• In normal security, Apple stores these service keys in iCloud so it can help you recover data. [Page 115]
• With ADP enabled, Apple no longer stores copies of these keys. Instead, the user’s devices are responsible for maintaining the sole copy2 of each of the Service Keys in iCloud Keychain. [Page 115]
• During iCloud sign-in on new devices, users go through a pairing process which adds the new device to a list of trusted devices for iCloud Keychain. [Page 130]
• This is a slight simplification, but basically the iCloud Keychain encrypts each item stored in the keychain with a public key for each of the other devices in the trusted devices list. Each individual trusted device decrypts item updates from other devices to maintain a shared keychain. [Page 130]
• The documentation states when ADP is enabled3 “…the device begins an asynchronous key rotation operation, which creates a new service key for each service whose key was previously available to Apple servers. After the service key rotation is successful, new data written to the service can’t be decrypted with the old service key. It’s protected with the new key which is controlled solely by the user’s trusted devices, and was never available to Apple.” [Page 116]

How I Expect Account Recovery With ADP To Work

The path for recovering an account’s security in this model seems simple. Content stored in iCloud at time of compromise must be considered compromised. However, after all compromised devices are removed from the iCloud Keychain’s trusted devices, rotating the service keys will ensure future content is encrypted with new keys unavailable to the attacker, and thus safe. (There is an added wrinkle around the the iCloud Keychain escrow mechanism, but we’ll put that aside for now.2)

So, how do we rotate those service keys? Well, the documentation indicates that the keys should rotate when ADP is enabled. Also, it seems like common sense that the keys should also rotate after the user goes through the recommended flow for an account compromise.

If Apple does not rotate the keys as they say they do after ADP is enabled, Apple could continue to access data for users that have ADP enabled. Furthermore, if the keys are not rotated after an account compromise, then an attacker who steals the keys once could persistently continue to access data from the iCloud account even after the user has tried to re-secure their account following the documented instructions.

Do The Keys Actually Rotate?

Not content to just trust the documentation, I set out to try to verify that it actually works. I relied on Apple’s open source releases and available tooling like ckksctl so that I could poke around iCloud’s internals without much difficulty.

My best guess based on my own sleuthing and prior work by other researchers is that what the documentation calls “Service Keys” in the documentation are actually called “CloudKit Keychain Service Top-Level Keys”, or “CKKS TLKs” in Apple’s source code and utilities. You can see monitor the current status of all CKKS TLKs using the ckksctl command line utility4. You can also inspect their storage in iCloud Keychain by opening Keychain Access on macOS.5

I tried two paths to try and get my TLKs to rotate.

The first thing I tried was to simply toggle ADP on and off, and to watch to see if the keys change in ckksctl or Keychain Access. I tried multiple times on multiple accounts and never witnessed a rotation.

The second thing I tried was to reset my iCloud password. Although the iCloud password is not specifically tied to the TLKs, this is what the Apple documentation says to do in the event of an account compromise. I used the “Reset Password” path where I selected that I needed to reset my password because I thought someone had hacked my account.

Neither of these methods produced an change in the TLKs visible via Keychain Access or ckksctl. Thus, I assume the keys did not rotate.

Conclusion: Something Smells Funny To Me

I need to be clear about the limits of my findings: I cannot say for certain that this represents a security vulnerability in iCloud ADP. It is possible that I am misinterpreting the output of Apple’s undocumented ckksctl tool or that there is some other undocumented mechanism to ensure security.

I think that this warrants further investigation. The next step I would take in an investigation is to do something like this:

1. Record the upload of the service TLKs to Apple,
2. Enable ADP on the iCloud account under test
3. Wait some time, as Apple specifies the rotation to be asynchronous
4. Create some new content (e.g. a new note) and let it be synced to iCloud
5. Fetch the ciphertext of the note from iCloud
6. Try to use the earlier captured TLK to decrypt the key hierarchy and then ultimately the note.

I think that if this path can be done successfully, it would clearly show a vulnerability in the iCloud ADP scheme.

Unfortunately, as far as I can tell, it would take substantial time and resources for me to develop all the supporting tooling needed to carry out this test. It would basically involve re-implementing a large part of the iCloud client.

I know that some people have already done this work, so it probably does not make sense for me to duplicate it. In particular, there is at least one data forensics firm that sells proprietary tools to law enforcement to do almost exactly this task.

That is why I am now disclosing my findings publicly. If iCloud really does not rotate the service keys, this is a real security flaw presents a risk to users. I think this public disclosure gives the best chance of another researcher who does have access to the supporting tooling to see my findings. Hopefully they further investigate and validate or disprove my findings. Furthermore, if it is a real problem, it is likely that some attackers have already noticed. After all, iCloud is a popular, high profile target, and this is would be a relatively simple flaw to exploit.

If anyone does double check my work and come to a definitive conclusion, please reach out at x at g1a55er dot net.

Appendix: My Vulnerability Report to Apple

For full transparency, I have included my vulnerability report I sent to Apple. I submitted this report to Apple’s Security Research report portal on August 30, 2023. It was assigned report identifier OE1953209343515.

# Affected platform
Apple Devices and Software

# Affected area
Cryptography

# Title
iCloud CKKS TLKs Not Rotating After Enabling ADP

# What is required to reproduce the issue?

1. An Apple ID. (I used the test account "adp-rotation-test@g1a55er.net")
2. A Mac running macOS 13.1 or newer. I used a Mac Mini (M1, 2020) running macOS 13.5

# Summary 
According to page 116 of the the Apple Platform Security document, the user's iCloud service keys should rotate after each time the Advanced Data Protection (ADP) setting is enabled. 

I interpret this to concretely mean that the new CKKS TLKs should be generated after ADP enablement. I do not observe this rotation happening after I turn ADP on via Keychain Access or via the `/usr/sbin/ckksctl` utility. 

My concern is that if my finding is correct, this would mean that the encryption keys that Apple claims would have never been available to Apple under Advanced Data Protection might actually have been recorded by Apple. Furthermore, I am concerned that if there is no way to rotate these keys, it is impossible to recovery forward secrecy once an iCloud account including the keychain has been breached by an attacker. 

#### Steps to reproduce
1. Sign in to the Mac with an Apple ID. In my test environment, this Mac was the only trusted device on the account, as to rule out cross device syncing as a source of the problem. 
2. Record the output of `/usr/sbin/ckksctl status` as well as the contents and modification timings of the records of kind `tlk` in Keychain Access. Note that to see the `tlk` records in Keychain Access you must enable "Show Invisible Items" in the "View" menubar menu, and you must search in the iCloud Keychain. 
3. Enable Advanced Data Protection via System Settings
4. Again record the output of `/usr/sbin/ckksctl status` as well as the contents of the `tlk` items in Keychain Access. 

# Expected results

- `/usr/sbin/ckksctl status` should indicate that new TLKs are in use for each of the services, and that the `lastNewTLKOperation` occurred recently.  
- Keychain Access should indicate that the `tlk` items have changed via inspecting their UUID names, their contents, and their modification times. 

# Actual results

- `/usr/sbin/ckksctl status` indicates that the same TLKs are in use after ADP is enabled as were in use before ADP was enabled. It indicates that `lastNewTLKOperation` was "never", although note I believe this actually this simply means the `lastNewTLKOperation` has not occurred since the start of securityd. 
- Keychain Access indicates that `tlk` items have not been modified in some time, and their names and contents match what they were before ADP was enabled. 

The documentation states that the rotation is "asynchronous", so I also repeated these tests after waiting 24 hours with the same results. 

# Implications 

My current understanding is that the CKKS TLKs are the highest root of the key hierarchy used for the iCloud service data encryption, and that these are the keys that are stored in the "available-after-authentication" hardware security modules (HSMs) under standard iCloud security protocols. I have come to this understanding after reading the Apple Platform Security document, source code released by Apple as part of its open-source contributions, and the work of other security researchers. Nonetheless, Apple has not elaborated publicly on this point explicitly, so I cannot be 100% certain. 

If this is true, and the TLKs are the highest level of the hierarchy, then the failure to rotate these keys after ADP is turned on represents a failure to deliver on the security properties promised by Apple for Advanced Data Protection, and would clearly allow an attacker who obtains the service keys before ADP was enabled (e.g. by taking it from the HSMs) to continue to steal new, fresh data uploaded to iCloud after ADP is enabled. 

If this is false, and the TLKs are only a middle level of the key hierarchy, it still may pose a security problem that these keys are not rotated. In particular, it would mean that it would be impossible to recover to full security after an iCloud account's Keychain was compromised by an attacker. The attacker might be able to still use previously stolen TLKs to continue to decrypt the victim's data after the victim changes their iCloud password and removes all trusted devices as recommended by Apple's documentation. This is because the new trusted devices signing in with the new iCloud password would still use the old TLKs for CKKS and thus Protected Cloud Storage objects. I additionally tested the password reset flow where I indicated that I believed my account was compromised to test this attack, and this flow also did not result in TLK rotation. 

# Coordinated Disclosure Timing
If I do not hear back by September 14th indicating that this report represents a genuine vulnerability and that Apple intends to make a fix, I will assume that Apple is not treating this as a vulnerability and might publicly disclose my research so far so that I may better collaborate with other researchers. 

If this is as a genuine vulnerability, I generally abide by Google Project Zero's industry standard disclosure timing guidance. 

I thank you for your time and diligence in investigating this report. As someone who handled some vulnerability disclosure reports in my previous day job, I sincerely apologize if I am misunderstanding some part of this system and have produced an erroneous "noise" report. 

Thank you again for your time, 

- g1a55er

1. I am fully aware of Betteridge’s law of headlines. I am attempting to subvert it in my corner of the Internet. When I write a headline that ends with a question mark, it means that I am actually unsure what the answer is. In this case, I am unsure whether or not this behavior can be exploited, and am open to be persuaded in either direction. ↩

2. There’s also an escrow mechanism for easier iCloud Keychain recovery. It’s described on page 131 and 132 of the Apple Platform Security documentation. It’s fairly complicated - it presents the user with a lot of options with various non-obvious trade-offs. So, I’d like to postpone discussing it at length until I can dedicate time to it justice in its own post. For the purposes of this post, I’ll just assume I have a reliable way of rotating this escrow record on demand, or that the threat model does not demand rotation of the escrow record to restore security. ↩ ↩2

3. One thing I considered is that Apple might for some reason only do this when ADP is first enabled, but that does not make any sense for two reasons. The first is that I also tested freshly enabling ADP on a new account for the first time and did not see TLK rotation. The second is that if you disable ADP, according to page 117 of the Apple Platform Security documentation, your device re-uploads the service keys to Apple. So to fulfill the promise that Apple never had access to your keys, it must rotate them each time ADP is toggled. ↩

4. I compared the UUIDs shown in the the “Current TLK”, “Current ClassA”, and “Current ClassC” fields shown for each service in the output of the ckksctl show command. I assume the “Current TLK” field is for the Top Level Key for that service, and then the ClassA and ClassC keys are the complete protection and “protected until first user authentication” protection levels documented here. ↩

5. To see the TLK items in Keychain Access, make sure you have the “View” -> “Show Invisible Items” option enabled, and then search for “tlk” while selecting the iCloud Keychain in the left sidebar. ↩

Tim Perry recently claimed in an article that “Android 14 blocks all modification of system certificates, even as root”. This sparked significant discussion on Hacker News. Thankfully my tests show that it is still possible to adjust the system certificate store in Android 14.

Update Sept. 15 2023, 6:34 AM Pacific: After I’d already written this post but before I posted it, it looks like Perry already discovered that he can solve this problem for his purposes by bind mounting the /apex/ mount back to the /system/ partition in the namespace of zygote and the children of zygote. The core of the idea came from a Mastodon thread with @tbodt and @tmw. This post still provides a slightly alternative method, so it is still relevant, as well as still being relevant to the broader discussion.

Users Can Still Revoke System Certificate Trust Through the Settings App

The headline of Perry’s article asserts that even root users cannot “modify” the system certificates at all. In fact, even in Android 14, all users can still remove certificate authorities (CAs) from the list of trusted CAs in the Settings app, just like they could in previous versions of Android.

To confirm that the Settings app still works, I used an Android 14 emulator to revoke trust from all the Amazon and Starfield Technologies CAs. I then accessed Amazon Trust Services Repository’s test pages using Chrome. They failed to load due to an untrusted CA. I also confirmed the revocation of trust persists across reboots.

Based on this, I think the headline of Perry’s article is overly strong. Most of the more impassioned comments on Hacker News took the headline’s strong claim at face value. It is important to be clear: users still retain ultimate control over the trust anchors in Android 14.

Developers Can Still Add Trusted System Certificates via ADB

When I revisited the article after reading Perry’s comments on HN and Mastodon, it became clear that his primary concern was the inability to easily add temporary system CAs via ADB. This feature is critical for his product, HTTP Toolkit. It is also critical for many other security researchers and app developers, myself included.

While Perry correctly notes that the traditional method no longer functions with Android 14, the feature hasn’t been discarded.

I initially anticipated a deep dive into APEX and its signing intricacies. Thankfully, a simpler, albeit somewhat crude, workaround exists for this as a proof-of-concept. This is not suitable for production use. For a production environment, it’s crucial to carefully limit SELinux and tmpfs security options to grant only the minimal privileges. Alternatively, one can construct a properly signed repacked APEX.

# These commands assume a root shell. 
#
# Deal with the fact that there will be executables on the /apex tmpfs
# !! Not suitable for production usage !! 
setenforce 0
mount -o remount,exec /apex
# Make a copy of the current conscrypt APEX contents
cp -r -p /apex/com.android.conscrypt /apex/com.android.conscrypt-bak
# Lazily unmount because conscrypt might be in active use
umount -l /apex/com.android.conscrypt
rm -rf /apex/com.android.conscrypt
# Put contents of conscrypt APEX on /apex tmpfs mount
mv /apex/com.android.conscrypt-bak /apex/com.android.conscrypt
# Soft userspace reboot to get everything back into a consistent state 
killall system_server
# Clear system trust anchors, if desired
mv /apex/com.android.conscrypt/cacerts /apex/com.android.conscrypt/cacerts-bak

Executing these steps clears the system CA list in the “Trusted credentials” section of the Settings app - the result desired in the original post.

This breaks through the mount namespaces by re-writing the directory entry for /apex/com.android.conscrypt on the /apex tempfs. The actual filesystem is shared between all namespaces, so overwriting this mount point has an immediate effect visible from all namespaces, even though the unmount event itself is not propagated. Hat tip to @tbodt on Mastodon for pushing me to dig into this until I fully understood it.

After this setup, adding trusted certificates is almost identical to prior versions. The only change is using /apex/com.android.conscrypt/cacerts as the destination path. I confirmed this by adding my personal CA as a system trust anchor.

This process only necessitates root access and doesn’t require altering /system. If you need persistence beyond a single boot, you’ll need to modify the /system partition, just as in older Android versions. Be prepared for the slight complexity of either deleting or repacking the com.android.conscrypt APEX. I leave that as an exercise to the reader.

Verdict: All Is Well That Ends Well

Yes, Android 14 has altered the behavior of its system certificate store. But users’ freedoms remain intact. The modifications just add a layer of indirection facilitating over-the-air updates to the certificate store. Given Android’s update delays have previously hurt CAs like LetsEncrypt, this is a positive move. I can see how the new layer may seems complicated at first, but it does have to meet some pretty tough constraints1.

Kudos to Perry for highlighting this change. Various tools will need to be updated to work with Android 14. Once that is done, I am optimistic that security researchers, developers, and reverse engineers will retain their previous capabilities to tinker and make.

Disclosures

I am friends with Googlers and former Googlers, but I have never worked for Google. I have previously worked as a security-focused developer for a small Android OEM, which is why this caught my attention. I do not currently work for anyone, so these opinions can only be my own.

1. Most notably, it must maintain security while allowing for different organizations in different positions in the physical smartphone supply chain to sign different parts of the Android system image. If you’re curious about theses trade-offs, Google discusses the alternative designs they considered here. ↩