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.
Regarding #1: iCloud in China is operated by a mainland Chinese company and subject to that company's terms and conditions. So you can pretty much assume iCloud data is completely accessible by the government.
Apple uses third party data centers, if it can't host encrypted data on a Chinese server without China having access to the data, there is something wrong with the encryption.
> On Wednesday, Apple officially handed over its iCloud operation in China to a local state-run company, along with all encryption keys to unlock local user data. The switch will give the Chinese government unfettered access to the photos, emails and contacts of over 240 million iPhone users in China.
> "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."
The keys exist on machines managed by the third party, which is controlled by the state. Therefore, the state has access to the data.
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...
I have not changed the subject. Apple clearly delineates which data is e2e encrypted and which data is not. Those same standards apply in the US and China - unless you have evidence otherwise.
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.
The laws of the US say a lot of things. But the facts are that all the government has to do is scream “terrorism”, “drugs”, “or think about the children” and they can easily get a warrant. The law states that one branch of government has to ask another branch of government for a warrant. You have to believe that the judicial branch actually would safe guard privacy and keep law enforcement from overreaching.
> You have to believe that the judicial branch actually would safe guard privacy and keep law enforcement from overreaching.
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.
You started this thread by responding to somebody discussing the Chinese government's access to all iCloud data
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.
> If some of the data is e2e encrypted using private keys,China doesn’t have access to “all 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.
The “key server” does not in fact “generate public keys”. It distributes public keys. But you can’t decrypt a message with public keys - that’s kind of the point...
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?
> The “key server” does not in fact “generate public keys”.
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.
Again, if it Apple were in fact creating their own key pairs on their server and sending users the key pair, don’t you think someone would have discovered.
But since it’s in a Wikipedia article, I guess that kind of closes the case.
> [If] Apple were in fact creating their own key pairs on their server and sending users the key pair, don’t you think someone would have discovered.
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.
> 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.
Seeing as how Apple complies with FBI and law enforcement requests to get iCloud data, that is definitely not the case in the US.
And that doesn’t make the statement untrue. Apple clearly lists which data stored on its servers are e2e encrypted. Those are all considered “iCloud data”.
I would urge you to read up on the Chinese cryptography law [1] which took effect on the 1st of this year. Essentially all companies foreign or not must provide unencrypted access to data to the Chinese government and must do so in secrecy. Prior to this, companies were being compelled to give up their data anyways but this just makes things easier.
By the way, the source below is an official Chinese government media source.
I've just read the article you linked[1], as well as several others [2][3][4] and cannot find any information about this:
>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.
Do you have any evidence that Apple rearchitected their system to have access to private keys that it doesn’t have access to anywhere, to have access to give it to China?
> It is the latest development in a pattern of Apple acquiescing to Beijing’s demands. Last July, Apple deleted VPN apps from the App Store that let mainland Chinese internet users evade censorship. Apple’s lawyers have also added a clause in the Chinese terms of service that states both Apple and GCBD may access all user data. Apple has not responded to requests for comment.
> 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.
Well, after actually reading the Reuter’s article that the verge citation is based on...
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.
> And even though Chinese iPhones will retain the security features that can make it all but impossible for anyone, even Apple, to get access to the phone itself, that will not apply to the iCloud accounts. Any information in the iCloud account could be accessible to Chinese authorities who can present Apple with a legal order.
> 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.
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.
> 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.
How many countries have laws that state user data must not be in foreign data centers?
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.
You need to brush up on your Cryptography 101 course before arguing with people about how asymmetric encryption keys work. There is nowhere that states that only one entity can have "control" of the keys. If you don't understand that, then I can see why you're so confused about this whole situation.
No. How the technology works is irrelevant when the end result is that the government wants the data.
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.
> 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'.
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.
FISA warrants can go multiple hops from the target which with network effects can sweep up tons of unrelated data from random people who happened to interact with someone who interacted with x bad guy.
That’s just for domestic surveillance keep in mind.
The only thing in that list that would is of interest to a government are messages. Fortunately no-one really uses iMessage in China. People use WeChat and (you guessed it) the Chinese government has access to these.
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.
>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.
E2E works exactly the same in China. You can read more in my comments here:
Please stop spreading disinformation. Your sources are outdated and the quotes that you are referencing are not legally binding. The fact is that Apple has clearly stated that iCloud data for Mainland Chinese users is stored on servers operated by a Chinese company, which must abide by the local laws and regulations. It is also a well known fact that all companies operating in China can be compelled by the Chinese government to provide data and do so in secret.
There's no disinformation in my comments. I seem to be one of the few people on the planet who seems to have actually dug into this exact issue while others only offer the typical FUD we've seen about how Apple's encryption works in China.
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.
> In fact I seem to be one of the few people on the planet who seems to have actually dug into this exact issue while others only offer the typical FUD we've seen about how Apple's encryption works in China.
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.
I think there might be misunderstanding about what exactly is "encrypted" and how. The comment 3 or 4 levels above says:
> 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 question and his answer were both completely clear. And most importantly, it's perfectly consistent with what Apple has said multiple times. You can believe they lied to a federal court and Congress if you want, but I certainly don't.
It was a reduction in security for Chinese iCloud users:
> 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.
Apple's decision to store the keys on Chinese servers was criticized because it effectively reduced security for Chinese iCloud users:
> 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.
This hard line is too facile. If you are paranoid about malicious code updates, then making part of your stack open-source doesn’t matter. I could push an update to your OS that reads the keys out of your BitWarden.
Yeah, I always verify the hashes of updated binaries match what I compile myself in parallel. Also that takes too much time so I just never update anything and have a homebrew version of 'Damn Vulnerable Linux'.
Long-term, there may eventually come a solution to this problem in the form of [binary transparency](https://wiki.mozilla.org/Security/Binary_Transparency). However, we're obviously a long way away from that being the norm, and there's still the problem of supply-chain attacks on hardware to consider.
I doubt the hardware supply chain can ever be secured. Even if you were to open-source every single part of manufacturing, there is no reliable way to ensure that the chip you, as a customer, have obtained, hasn't been backdoored. You'd have to delid it and put it under an X-Ray if that even resolves the tiny featuresin modern CPUs.
With an open hardware design, periodically de-liding and examining a random sample of available consumer hardware would probably sufficient to protect the general consumer population, and targeted attacks become very difficult if you purchase your hardware from a store rather than order it by mail.
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.
>With an open hardware design, periodically de-liding and examining a random sample of available consumer hardware would probably sufficient to protect the general consumer population, and targeted attacks become very difficult if you purchase your hardware from a store rather than order it by mail.
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'd have multiple trusted independent parties from multiple international jurisdictions reviewing the hardware design, not just one. And yes, obviously the X-Ray machines would need to be verified using similar techniques.
The same way you trust anybody? If you're so paranoid that you believe literally everyone is out to get you, then you're not going to be able to function in any society, let alone one as interconnected and interdependent as our own.
How do you trust your hash program? How do you trust the cryptographers who came up with the hash algorithm? How do you trust your compiler is faithfully interpreting the source code you're reading?
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.
Yeah, try to do that on a mainstream Linux distro for example.
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.
I meant that closed source even gets less safe when allowing auto-updates. When using opens source the auto-updates need to be trusted; yes. Nothing new.
I thought iMessage private keys are somehow based on data in the "secure enclave" chip, and thus not able to be stored in the cloud. It's my understanding that Apple could add new "devices" to listen in on future conversations, but it can't read iMessage conversations in transit between existing devices.
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.
If you lose your device and buy a new one and restore your device with a back up, all your messages will be returned.
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).
Maybe we're talking about different private keys? To clarify, here's how I think it works:
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.
The encryption is a bit complex on the iPhone, because keys are typically held by the secure enclave which enforces policy on use. These keys are both used to encrypt the base filesystem, and can be applied by policy against individual files.
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.
You are right; Apple isn't storing your private key, they simply have access to an unencrypted dump of your iPhone at the time of iCloud backup creation. My comment implies that once you take a backup, Apple would have the ability to read all your future messages as well.
> There’s no way to accomplish this without having the private key in the backup.
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.
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".
I would think that you could, however, encrypt that private key with a user-controlled password. (Granted, this should be optional and have big red warnings about being unable to recover without the password)
The secure enclave is a feature to secure the device and the data on it from casual threats. Apple gets a bit evasive any time the subject of security shifts to their cloud services. (i.e. they will talk about how a particular feature is e2e encrypted but their security talking points seem to mostly end at the device)
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.
> 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.
It's not uncommon for software to claim to offer this feature. Windows does it for example, and it was a bug in such a feature for WebCrypto in Firefox that made the news recently here.
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...
One thing to keep in mind with iMessage. Even if you back up locally the receiving party is probably using iCloud. So not sure how much it will really help.
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).
There are a few possible approaches. I figured they're using b2.
I'm pretty sure Synology has builtin tools to mirror to it. Backblaze will backup external drives that are attached to the computer, but if they are disconnected for 30+ days the data is deleted. While network drives aren't backed up there are ways to have them appear as local drives (which I hear are a pain to deal with).
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.
That works for any service where you don't fully control the other endpoint. They are just being transparent. Although the wording re: website is peculiar. Could it be their form of a canary like warning?
As a developer, I expect that smaller shops' infrastructure isn't as thoroughly locked down and things like passwords getting logged to splunk/ELK is tech debt, and par for the course. However that's a very specific exception though, to the point that instead of putting work into adding that into their disclaimer, they could have made sure the password wasn't being logged instead.
They deleted all of my data when one of my payments didn't go through, without notifying me. They are impossible to contact outside of passive aggressive email support. I deeply regret trying to trust this company with my data, which is now gone. Do yourself a favor before trusting them and give them a call and to ask about their services.
So do you need to decrypt the backup of your iMessages to get to the private key inside of it, or can apple see your private iMessage keys in the backup without needing to decrypt anything?
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.