[0]: https://www.theinquirer.net/inquirer/news/3061660/whatsapp-i...
Apple and Microsoft both tried to build ad businesses, but when they weren't as successful as Google, they turned lemons into lemonade by launching data privacy PR campaigns against Google.
Meanwhile, Apple and Microsoft quietly censor their products in China, surrender data to Chinese authorities, and now we find Apple is intentionally leaving iCloud data insecure.
Presumably Google was under the same pressure from US law enforcement, but somehow Google delivered end-to-end encrypted Android backups in October, 2018. And Google did it without all of Apple's self-congratulatory media hoopla.
e2ee: https://security.googleblog.com/2018/10/google-and-android-h...
Third party security audit: https://www.nccgroup.trust/us/our-research/android-cloud-bac...
Apple will store some iCloud encryption keys in China, raising security concerns https://www.theverge.com/2018/2/26/17052802/apple-icloud-enc...
I didn't say that Apple is right to do it in China or elsewhere. I merely pointed out that it's happening in one place and asked why that would make it moot elsewhere. I agree with everything you said except for the phrasing of your first sentence.
> Injustice anywhere is a threat to justice everywhere.
So I 100% agree.
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.
"iCloud services and all the data you store with iCloud, including photos, videos, documents, and backups, will be subject to the new terms and conditions of iCloud operated by GCBD."
And since all Chinese companies are bound by local laws, you can be assured that your data is readily available for access by the government.
The data that is available in China is not encrypted and would also be available to US authorities.
Can you quote the part of the article that states that Apple must give China private keys? Can you find a citation where a third party has found proof that Apple changed the iMessage architecture?
> Can you quote the part of the article that states that Apple must give China private keys? Can you find a citation where a third party has found proof that Apple changed the iMessage architecture?
Apple is smarter than to put some text on their official website saying that the Chinese government has access to all your data. The key here is that their Terms and Conditions state that they operate "...in accordance to local laws". This is a cop-out legalese way of saying "We abide by whatever the Chinese government tells us to do".
Apple doesn’t control “private keys” you use to encrypt data. The keys wouldn’t be very private if that were the case.
The entire idea behind public/private keys is that you keep access to your private key.
While technically they could do that, do you realize how much legal trouble they would be in in the US if they did so without disclosing it?
Alternatively, they would have to have a special build of iOS for China.
Also, none of the “citations” make mention that the Chinese law forces Apple to give private keys to China.
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
>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.
This means Apple can produce the data a government is looking for in virtually all cases, and that's probably good enough for China.
Another factor to consider is that SMS and iMessage are rarely used in China due to SMS historically being more expensive than email/data over there.
Email is the least secure method of sending data and always has been.
I’ve never paid attention to it until now, but you can selectively disable iCloud backups for any of the built in apps and third party apps in settings.
Email is the least secure method of sending data and always has been.
A placebo toggle is also an option.
And, well, Apple have confirmed that they‘re matching on your data[1]. So, guess what?
[1] https://www.scmagazine.com/home/security-news/apple-scans-ic...
It would be nice if Apple was more forthcoming with that fact but there is some onus on the customer these days to understand what's private and what is not.
https://support.apple.com/en-us/HT202303
iCloud backups are not on the list of end-to-end encrypted.
“For certain sensitive information, Apple uses end-to-end encryption.”
“These features and their data are transmitted and stored in iCloud using end-to-end encryption:”
* 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
If “backup”, photos, messages, contacts, calendars, iCloud Drive, notes, and safari data (and a few more) are end-to-end encrypted what else is there?
The list of E2E is further down, separate from the table, and includes: 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, and Wi-Fi passwords. So virtually nothing, by comparison.
Messages, probably the most personal and relevant for legal cases, are end-to-end-encrypted as well, but if you have iCloud Backup enabled, the key is stored in the backup, making this useless.
But distinguishing PR bullshit from actual practice is essential when navigating the dystopia.
Even the 2016 blackhat talk on youtube, which describes an elaborate signing mechanism for updates, doesn't preclude shipping targeted OS updates to individual users. Maybe I missed something though, and in that case I'd appreciate you pointing it out.
The reality is it’s way easier to just exploit a weakness that you can text someone [1].
But if you’re dressed in tin foil hat to toe, then there’s nothing that I can say to convince you. At that point I’d suggest not using any computing technology that you don’t personally build yourself and watch 24/7.
[1] https://www.nytimes.com/2020/01/21/technology/bezos-phone-ha...
Edit: Also, it's compelled speech though.
IIRC it said it wouldn't bow down on implementing back doors to unlock protected devices and encrypted content on them, which is specific enough not to cover this case.
Bowing down on implementing new security features doesn't go against the promise to not bow down on the security of existing ones, as written. It can be argued to go against the spirit of the earlier public statement of course, but that doesn't count for much in the eyes of a corporation being given a strong suggestion by a government agency.
It is a front door convenience feature which has distinct privacy/security trade-offs.
There exists no magical way to provide a means of lost password/device recovery which doesn’t grant Apple access to decrypt your data. It turns out that a lot of users want to have a way to recover from a lost device/password and are willing to let Apple decrypt their data.
You do this by ticking the ‘iCloud Backups’ toggle on your iPhone.
A backdoor by definition is not a user facing and configurable feature which is thoroughly explained in end-user documentation.
In modern times your face and your fingerprints could be that magic.
The thing doing the authentication can be your local device, or a cloud-device. That thing must necessarily store a validator for your face/fingerprints which it can use to decide your submitted capture is “close enough” to consider a match, after which it grants access to the key, usually indirectly, by allowing certain cryptographic operations with the key.
Apple takes pains to ensure the biometric validators never leave the Secure Enclave of a local device. Possibly they could allow syncing these validators between Secure Enclaves of paired devices but I think you have to re-enroll. Absolutely never do they transmit these biometric validators to the Cloud in a readable form.
So in a lost-device scenario, you are also losing the biometric validators as well as the keys which were unlocked by the validators.
I think storing decryptable biometric validators is worse than storing decryptable device backups. Such a fingerprint database would almost certainly be abused by a government (forced to match a terrorist’s fingerprint against their users).
The singular reason I am willing to use biometric authentication on my phone is because the authentication is done locally.
For example Amazon’s recently announced project to link Amazon Pay to a palm print in stores is a total non-starter for me. Besides the fact that it’s a clumsy and bad idea to begin with, no way I want them having my palm print validator sitting in the Cloud.
My assumption is that device recovery is such a special case, that it can use very different algorithms than those used in phones today, they could be very computationally expensive and turn fingerprints into usable keys. And of course there is no need for anyone to store them or being able to match them individually or even just tie to an identity of a person.
Encryption keys are precise integer values (or can be represented as such) and they gain a large part of their security from two facts; a key that is wrong by even one bit will appear totally wrong / disclose zero information, and two, the key space is unfathomably large.
To turn a fingerprint directly into an encryption key would require first; some sort of mapping between the analog representation of the finger/face (which could be two or 3 dimensional) into a digital value, and second; for that value to be absolutely repeatable over time.
The biggest problem is that of course neither your face, nor your fingerprints, are absolutely unchanging over time.
So the first thing you would somehow need to accomplish is a way to map the biometric scan to a repeatable precise integer value. Such a mapping would require, by definition, a loss of precision.
How much precision? Well, it’s directly a result of how resilient you want the algorithm to be in the face of things like scanning error, micro-abrasions on the finger, body fat percentage, the temperature of your hand, swelling, hair growth, etc...
The less precise you make it, the more different fingers (or different scans of the same finger) must necessarily resolve to the same key.
This is the same thing as saying that we are reducing the key-space.
Once you have reduced the precision of the mapping from a biometric scan into a key that will reliably generate the same key over time, you have, by definition, reduced the key space to the point where the encryption is fundamentally unsound.
The only exception to this would be perhaps using DNA sequences, but even then, I believe DNA is not actually perfectly unchanging over time, and is also not at all random [1]. But assuming you could probably handle the minute coding changes that do occur, and reliably scan the same part of the genome, I think you could end up with enough entropy to generate a secure key. Assuming you are willing to precisely sequence a chunk of DNA in order to generate your key. This is rapidly becoming feasible, if not somewhat dystopian and entirely impractical.
But you still have the fundamental problem that the key is not being generated as a uniformly random value in the key space. This happens to be extremely important to the security of encryption algorithms. You wouldn’t want, for example, a close relative to be able to cut your entropy from 512-bits down to 64-bits and into the realm of brute force.
In short, biometrics will remain an authentication method rather than a direct encryption method, likely indefinitely.
Refreshing it every few years isn't a big deal (as obviously none of it will be used directly as an encryption key for all of your data, but only to encrypt an actual encryption key).
[1] https://backend.orbit.dtu.dk/ws/portalfiles/portal/180163248...
It doesn’t seem like you read my reply at all.
It’s not a question of raw entropy from the sensor, which is what the paper is discussing. It’s an issue of repeatability.
It isn't a deliberately implemented backdoor. It is a deliberate decision to not install doors at all, just empty frames. I know we are arguing semantics here, and it doesn't make it right, but it doesn't go against the letter of how they've claimed they'll behave.
Disclaimer: I work for Apple.
It’s not just marketing.
This is a crappy place to turn around and tell your customers, “should’ve read the fine print!”
Put yourself in their shoes. These companies stand to lose tens or perhaps hundreds of billions of dollars in foreign sales if there isn’t a counter-narrative to “well of course they spy for their national military, just look at these Snowden slides”. Making it seem like they are fighting for their customers at odds with the FBI is a perfect counterpoint.
Meanwhile, it’s business as usual for US military intelligence, as evidenced by TFA. Excellent reporting!