These are end to end:
Home data
Health data (requires iOS 12 or later)
iCloud Keychain (includes all of your saved accounts and passwords)
Payment information
QuickType Keyboard learned vocabulary (requires iOS 11 or later)
Screen Time
Siri information
Wi-Fi passwords
The messages also end to end but the backup contains the private key.
The moral of the story is that if you want real protection, do local backups.
1) There is no way Apple would be allowed to sell iPhones in China, without China government having access to anything. So, I assume that Apple users in China have e2e encrypted exactly nothing.
2) I have a strong suspicion that those 'enter your Apple ID password because your account needs it' message really means 'a government has requested your data and even though it's encrypted, we will nag you about entering a password, and if you give it, you're a free game'.
I don't blame Apple for this, I'm sure they're doing what they can, but when a government says 'give us this data', they can't not comply. Vote responsibly - companies can't protect us from a government we have put into power.
> Chinese users of Apple’s iCloud service will see their data–along with that data’s cryptographic keys–stored inside the country beginning Wednesday, Reuters reports. The move will mean that Chinese authorities will have easier access to Chinese users’ iCloud data than before when that data was stored in the U.S. The move is a contentious one, as human rights activists say Chinese authorities will now have an easier means of obtaining dissidents data since it no longer needs to go through the U.S. legal system to get Apple to hand over its cryptographic keys for Chinese users.
https://www.fastcompany.com/40535933/apple-will-store-icloud...
Haha I hadn’t thought of that. If true, I must have every government requesting my data frequently as I constantly get bombarded to enter my iCloud password.
That’s just for domestic surveillance keep in mind.
By the way, the source below is an official Chinese government media source.
[1] http://www.xinhuanet.com/english/2019-10/26/c_138505655.htm
If your boss asks you to build a machine that produces a widget, does he really care what your code looks like? Probably not. In the same vein, Apple can figure out whatever solution they want, whether it involves conventional use of encryption keys or not, to provide a system where the Chinese government can get access to their users' data.
It's really not that hard.
> Meanwhile, Chinese laws do not protect internet users’ privacy from government intrusion. In 2015, China passed a National Security Law, which included a provision to give police the authority to demand companies let them bypass encryption or other security tools to access personal data. The National People’s Congress was not available to comment.
https://www.theverge.com/2018/2/28/17055088/apple-chinese-ic...
Apple says the joint venture does not mean that China has any kind of “backdoor” into user data and that Apple alone – not its Chinese partner – will control the encryption keys. But Chinese customers will notice some differences from the start: their iCloud accounts will now be co-branded with the name of the local partner, a first for Apple.
> Apple said it will only respond to valid legal requests in China, but China’s domestic legal process is very different than that in the U.S., lacking anything quite like an American “warrant” reviewed by an independent court, Chinese legal experts said. Court approval isn’t required under Chinese law and police can issue and execute warrants.
https://www.reuters.com/article/us-china-apple-icloud-insigh...
> That means Chinese authorities will no longer have to use the U.S. courts to seek information on iCloud users and can instead use their own legal system to ask Apple to hand over iCloud data for Chinese users, legal experts said.
U.S. courts are highly unlikely to order Apple to release iCloud data to Chinese officials. Any cases would be public and attract international media attention. For Chinese iCloud users, that makes all the difference.
Every company in the US has to comply when it’s ordered by the court to give up user data. The US justice system is not exactly a shining light on the hill when it comes to needing a high bar to give investigators search warrants. All someone has to do is say “terrorism”, “drugs” or “protect the children” and courts will fall over backwards.
Also from the same article:
Until now, Apple appears to have handed over very little data about Chinese users. From mid-2013 to mid-2017, Apple said it did not give customer account content to Chinese authorities, despite having received 176 requests, according to transparency reports published by the company. By contrast, Apple has given the United States customer account content in response to 2,366 out of 8,475 government requests.
You have much more faith in the US justice system than I do.
> Until now, Apple appears to have handed over very little data about Chinese users. From mid-2013 to mid-2017, Apple said it did not give customer account content to Chinese authorities, despite having received 176 requests, according to transparency reports published by the company.
By moving iCloud data and keys to China, the amount of data Apple handed to Chinese authorities on Chinese iCloud users went from zero to a nonzero amount. Therefore, Apple degraded the security and privacy of Chinese iCloud users by making the switch to Chinese servers.
Due process is much more frequently ignored in China than in the United States, but that fact isn't even necessary to establish that Apple's switch to Chinese servers negatively affected Chinese iCloud users. The above is sufficient.
https://web.archive.org/web/20111019034145/http://www.law.ya...
>all companies foreign or not must provide unencrypted access to data to the Chinese government and must do so in secrecy
either plainly stated or implied.
Can you provide a source for this claim? I don't doubt that this may occur, but I'd like to speak with _my own_ managers about my china & encryption concerns in an informed way.
[1] http://www.xinhuanet.com/english/2019-10/26/c_138505655.htm
[2]https://www.insideprivacy.com/data-security/china-enacts-enc...
[3]https://thediplomat.com/2019/10/decoding-chinas-cryptography...
[4]https://www.iflr.com/Article/3907570/PRIMER-Chinas-cryptogra...
Edit: Apple itself has stated that the keys are in China. The option of having Apple devices talk through the Great Firewall to servers in the US that then encrypt the data for storage in China (and on the querying end, request encrypted data from China to decrypt and process in the US to serve back to devices through the Great Firewall) that Apple apologists wishfully theorize is every bit as ridiculous as it sounds. https://www.reuters.com/article/china-apple-icloud/rpt-insig...
If you want to change the subject and talk about iMessage instead of iCloud, the architecture of that system allows for the government to intercept all messages as well. https://www.wired.com/2015/09/apple-fighting-privacy-imessag...
I no more trust my privacy to the US government than a Chinese citizen should trust China.
You started this thread by responding to somebody discussing the Chinese government's access to all iCloud data, but you changed the subject to talk about systems where the private key is on device, which does not apply to iCloud. You absolutely did change the subject.
> Those same standards apply in the US and China - unless you have evidence otherwise.
Those same standards don't actually protect your data from whoever controls the iCloud server or whoever controls the iMessage key server. In the US, that is Apple, so Apple has access to that data. In China, that is the Chinese government. Therefore, the Chinese government has access to all Chinese iCloud and iMessage data.
> I no more trust my privacy to the US government than a Chinese citizen should trust China.
Then you are unfamiliar with the laws of both countries.
If some of the data is e2e encrypted using private keys,China doesn’t have access to “all data”
Those same standards don't actually protect your data from whoever controls the iCloud server or whoever controls the iMessage key server.
If the private key is generated by the same entity or “key server” that generates the public key, and then transmitted to the client. That kind of defeats the entire purpose of public/private key encryption.
I’ve never seen an implementation of public/private key encryption where the client device doesn’t create the key pair and send only the public key to encrypt data.
You have two mistakes in this sentence.
1. None of the iCloud data (mail, docs, drive, etc.) is E2E encrypted. Some of the data stored in iCloud (like keychain backups) is encrypted prior to being sent to iCloud (using symmetric encryption, not with asymmetric key pairs). China has access to the data that was ultimately sent to iCloud.
2. The way Apple implements E2E encryption for services like iMessage that are E2E encrypted allows China access to that data.
> If the private key is generated by the same entity or “key server” that generates the public key, and then transmitted to the client.
That's the point. Since Apple's implementation relies on a key server to distribute public keys, it is straightforward for the key server to generate its own key pair and serve a fraudulent public key to the recipient, decrypting and re-encrypting messages that the iMessage servers relay. Apple relies on the technical illiteracy of its users to get away with its deceptive and often plain false marketing claims. Now you know better.
But after reading research from security experts you have found a citation where Apple is generating a key pair from its servers and sending the private key to the client?
That's the point. It should not, but the security model of iMessage allows the key server to get away with it, which is almost certainly happening in China right now. Try reading the article and following the example.
> But after reading research from security experts you have found a citation where Apple is generating a key pair from its servers and sending the private key to the client?
No, it sends the public key. Encrypting messages is done with the recipient's public key. Go read the Wikipedia article on asymmetric encryption. Because the owner of the keyserver can send its own public key, it can decrypt messages with its own private key before re-encrypting with the intended recipient's public key.
But since it’s in a Wikipedia article, I guess that kind of closes the case.
You once again misunderstand the vulnerability. The vulnerability is that China does this because China controls the keyservers in China.
As far as anybody discovering this, that would be very difficult because Apple does not let you install your own apps on the device and would not approve an app designed to detect this.
But even more, why would they bother? People who care about their privacy will simply avoid closed source software and especially closed systems like Apple's instead of trying to use a known compromisable system safely.
>But since it’s in a Wikipedia article, I guess that kind of closes the case.
I was pointing you to a place where you could learn about cryptography because you seem not to understand the basic concepts. The Wikipedia article does not describe this particular vulnerability.
Seeing as how Apple complies with FBI and law enforcement requests to get iCloud data, that is definitely not the case in the US.
These warrants become public record. I don't have to blindly believe it. I can look at the records and see that the US is not even close to China as far as government access to user data.
Unless the government screams “terrorism”. Ever heard of a FISA warrant?
https://www.ajc.com/news/national/what-fisa-warrant/WqP428Eg...
https://observer.com/2018/03/apple-grants-china-full-control...
> "The simple fact is that once the encryption keys are stored on Chinese servers, they will be easier for Chinese authorities to access — with or without legal requests," says Sharon Hom, executive director of Human Rights in China, a US-based NGO. "Since Apple has declared its willingness to 'comply with Chinese law,' its reassurance that it, not its Chinese partner, would control the encryption keys is not exactly reassuring. In addition, Chinese authorities could bypass Apple to address their requests directly to Apple’s Chinese partner, a state-owned enterprise that, of course, would have to cooperate with Chinese authorities."
https://www.wired.co.uk/article/apple-icloud-china-iphone-da...
The libertarian party surely would but most people don't even know it exists, i would guess.
E2E works exactly the same in China. You can read more in my comments here:
https://news.ycombinator.com/item?id=20904857
The same "vulnerability" of being able to respond to legal requests for iCloud data that exists in China exists everywhere else in the world.
The fact is that Apple has said multiple times (and even under oath) that end-to-end encryption applies to iPhones and iMessage in China, the same as it does everywhere else.
And once again Erik Neuenschwander, an Apple privacy exec, told Congress in a hearing in December that this was still the case.
At 02:10:46
https://www.judiciary.senate.gov/meetings/encryption-and-law...
I think instead of researching how Apple works in China, you need to start doing some research on how the Chinese government works and their track record on legal matters and rule of law.
Also, the segment in the Senate hearing you referenced shows a senator who obviously does not have a good grasp on encryption technology asking bumbling questions about encryption. I have paraphrased the section here:
> Senator: Do you sell phones in China? Are they encrypted? > Apple: The phones are the same and all of our phones are encrypted across the world
Yes, obviously all phones have encryption but the Senator did not clarify what was being encrypted here and Apple took advantage of this in the response.
> Senator: You're telling me that they [China] allows you to sell devices without you allowing them to breach the encryption and gain information about the users? > Apple: You're 100% correct
Once again, the question posed was incoherent. Of course there is no "breaching of encryption" here - the Chinese government just asks for the keys or the data. It's all about language here.
If this Senate hearing is your case for why data is safe in China, I honestly fear for all the political and religious dissidents that are trusting Apple for their safety.
> The same "vulnerability" of being able to respond to legal requests for iCloud data that exists in China exists everywhere else in the world.
And an article on Apple's site [1] confirms that most data in the cloud are "encrypted", but without E2E encryption, possibly in a reversible way. That article also notes that while messages are E2E encrypted, a cloud backup might contain a key to decrypt them:
> Messages in iCloud also uses end-to-end encryption. If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices.
So it is possible that the data on the phone are encrypted, the data in transit are encrypted, the data in the cloud are encrypted for every user in the world, but the cloud operator has the encryption keys for some of the encrypted data: Chinese operator for data of Chinese users and Apple for everyone else. This doesn't contradict neither with Apple's statement nor with the article nor with that comment above.
> The U.S. company is moving iCloud accounts registered in mainland China to state-run Chinese servers on Wednesday along with the digital keys needed to unlock them.
> In the past, if Chinese authorities wanted to access Apple's user data, they had to go through an international legal process and comply with U.S. laws on user rights, according to Ronald Deibert, director of the University of Toronto's Citizen Lab, which studies the intersection of digital policy and human rights.
> "They will no longer have to do so if iCloud and cryptographic keys are located in China's jurisdiction," he told CNNMoney.
https://money.cnn.com/2018/02/28/technology/apple-icloud-dat...
As for the End-to-End encryption of iMessage it is a bit overrated. Apple does the key management for you. So theoretically they could pretend that the key of your interlocutor recently changed (because new phone or something), it would just work transparently. So if a "nefarious" entity were to gain access to iMessage servers, they could use that technique to decrypt, "on the fly", the messages of whoever they want to spy on, without the clients knowing that this even occurred.
When you use "WhatsApp" you have the ability to get some kind of warning when the interlocutor's key has been updated. It's also possible to check each others' identity by scanning some kind of QR Code. But the app does not really put any emphasis on which accounts have been verified. Signal is about as bad as WhatsApp. My guess a government that wants to spy on your WhatsApp/Signal messages probably could, because most people would notice the key change warning nor understand what it means.
Only Apps which makes a big fuss about key management (Threema for example) are properly End to End encrypted, with no possibility for Big Gov to hack into servers and spy on you by adding their keys to conversations. But then they would probably just hack the OS on your phone at this stage. In fact that method, is probably better than messing around with iMessage/WhatsApp servers. You bypass ALL forms E2E encryption, and you get access to everything else, with one swift hack. I bet the NSA and their Chinese equivalents have such hacks in reserve for very juicy targets they want to spy on.
With the kind of unlimited budget the NSA has, it's hard to imagine something they cannot hack. That is why big A-list targets like Bin Laden went totally off-grid for communication.
But.. the electoral college.
Apple could (have) issue(d) an update with code to steal yr anything, without you knowing, so FBI-or-whatever does not "complain".
I currently use one e2e service, BitWarden as keychain, that ticks the boxes (e2e AND open source client).
/s
Even so I agree that examining all hardware in that manner is impractical. A better approach might be having a small, simpler core of secure open-source hardware managing your root of trust, and trying our best to mitigate the impact of compromises in the more complicated components (like the motherboard, CPU, etc) with approaches such as requiring open source firmware, sandboxing individual components by filtering their external communications through open hardware, and limiting their access to sensitive data like encryption keys. Obviously there's only so far you can go with that, but I don't think it's an entirely hopeless battle either.
It's a very interesting problem for sure.
How do you trust the person that verifies the CPU? Can you trust the X-Ray imaging machine? Is the X-Ray Machine verified to be open source and not backdoored to hide backdoors (aka bootstrapping trust).
You can hash the source code and verify that what you have is the same that the developer shipped.
There is no hash function for hardware.
IMO if you're at the point where you believe you can't trust multiple decentralized, independent, multi-jurisdictional bodies all telling you the same thing: that the hardware they've tested matches the published design, you've reached a level of paranoia where no amount of reassurance, technological or otherwise, will satisfy you.
I suppose if you really wanted to you could build your own X-Ray machine from scratch and check the design yourself. That's probably not much more difficult than going line-by-line and manually verifying the source code of your entire software tool chain because you don't trust anyone else who's read the source code enough to believe them when they tell you they've already verified that everything looks correct and that your text editor probably isn't lying to you about the contents of your source files. Which is to say probably totally impractical, but again, that's kinda my point.
While I'm not saying maintainers & users are checking all changes in packages, all the work happens in the open & all the source is compiled on distro infrastructure.
So once you actually do an atack like this and it is discovered, you can be sure anything done by the maintainer will be combed with a very fine brush & the account disabled.
Given that it can take years to build the trust needed to become mainatiner of an important package, only to loose it all once you atack is known, I really can't see this used for anythin else than very targetted high stakes attack omce off attack, definitelly not for any long term dragnet surveilance.
Should this even be called E2E? I suppose it is, technically, but clearly not in spirit.
It can also read iCloud backups of conversation content, which are created by the client device after decrypting the message. But that's not the same as storing the private key itself in the backup.
Happy to have my understanding updated...
There’s no way to accomplish this without having the private key in the backup.
EDIT: When I say there is no way to accomplish this, I’m talking specifically about the process that exists today where the user doesn’t have to remember a password other than their iCloud password (which today, can also be reset).
Uh, no. There's no way to accomplish that without some kind of user-managed escrow (even a pass phrase would be fine). It's maybe not the seamless experience Apple wants to offer, but it's certainly not impossible.
Frankly the kind of dummyproof restore being offered is fundamentally incompatible with private backups.
1) To send you a new iMessage, someone else's iPhone Z encrypts it with your public key and sends it through the iMessage network. Apple can't read this message since they don't have your iMessage private key, which is only on your device.
2) Your iPhone A receives the encrypted iMessages and decrypts them with your iMessage private key on your device.
3) iPhone A stores the decrypted iMessage content in its filesystem, which is encrypted locally with the device private key (derived from your device passcode).
4) Time to backup... iPhone A decrypts its filesystem with your device private key, and sends filesystem contents as plaintext, through an encrypted tunnel, to an iCloud backup server, which encrypts the backup locally with an iCloud server private key, and stores it.
5) You get a new iPhone, let's call it iPhone B. iPhone B asks iCloud for a restore. The iCloud server locally decrypts the backup, and sends it to iPhone B as plaintext through an encrypted tunnel. iPhone B receives the backup as plaintext and stores it locally, encrypting it locally with the device private key.
6) iPhone B iMessage client loads the plaintext old iMessages into the Messages client for you to read.
At no point in this process would Apple have or store your iMessage private key or your device private key.
Example policies from the Secure Enclave would be that a private key is available on first unlock, only while unlocked, only while a PIN is set, and/or whether the key should be shared with other trusted devices.
The base filesystem is encrypted with a key released on boot, while individual files can be encrypted with some set of these policies. I believe this can be done either on individual files in an app's data, or as an entitlement to apply by default to the entire app. https://developer.apple.com/documentation/bundleresources/en...
My understanding is that files set with a policy that they are only available while the device is unlocked will still be backed up in the locally encrypted form. So, assuming Signal/WhatsApp/etc set a single flag their data is stored encrypted in iCloud.
Further, per your list I suspect that the backup data is sent to/from iCloud already encrypted by a secret - but that secret is shared with iCloud for recovery and shared further on official government request. The goal there is to limit the amount of unencrypted user data sent to third party servers (in this case in the US I believe Azure-hosted storage for backups).
The keys are separately stored on Apple-controlled servers in non-China countries. In China, I believe they were required by law to have the key storage instead hosted by a Chinese data center.
Your messages are returned via the backup, not via the "iMessage servers". Once the messages are at rest on your device, they're no longer encrypted using your "iMessage private key".
> Messages in iCloud also uses end-to-end encryption. If you have iCloud Backup turned on, your backup includes a copy of the key protecting your Messages. This ensures you can recover your Messages if you lose access to iCloud Keychain and your trusted devices. When you turn off iCloud Backup, a new key is generated on your device to protect future messages and isn't stored by Apple.
But wait does it mean that if you haven't iCloud backup activated but use local backup you can actually sync message without storing private key... the wording here is important would be nice if someone clarify.
iMessage doesn’t use the backup for syncing. If you want to sync then both devices need to be logged into your account.
You can turn off iCloud backup for messages (with or without a local backup).
Maybe the concept is the same, but on a Mac the private key is stored in the Keychain instead of a physical enclave?
Invariably such features are weak and a sufficiently capable attacker can override them. In Windows for example you could reach into the opaque data structure and toggle the Boolean that forbids exporting keys...
I think a better way to look at what they're selling you is a device that provides you pretty-to-very good protection from casual hacking and theft. But in the event of a government knocking on their door for more information, they'll quietly hand over what they can which probably is quite a bit more than the average consumer thinks it is. All bets are off as to what the full story is when the government/jurisdiction involved is not the United States.
Yes, this is unfortunately true and unfortunately complicated compared to iCloud backups.
I backup locally to my mac (encrypted), then I have my mac do time machine backups to my Synology NAS (encrypted) and then I have my NAS backup to BackBlaze (encrypted). I do that to satisfy the two pronged backup strategy: local (fast) and remote (slow, but useful in catastrophic local situations such as fire, flood, theft, etc).
Yes exactly, this is what I'm using. There is a time machine folder on the NAS, the Synology tool mirrors that encrypted folder to backblaze. I have the backblaze sync set to run at 1am so it's not uploading and affecting my bandwidth while I'm (typically) awake. Yes, my remote backup is up to 24 hours behind my local time machine backup, but this is acceptable to me since it's only for catastrophic recovery.
NOTE: Logging in via the SpiderOak website does temporarily allow SpiderOak employees access to your password.
https://spideroak.support/hc/en-us/articles/115001854583-ONE...