Just so you know when I forgot the password to my password to my iPhone remembered that I choose 1 from the top section 2 repeated numbers from the row below 1 below that and then a zero. So I tried it untill it said "iPhone disabled connect to iTunes", this is when I found out you can reset the disabled time by clicking on a computer the backup button. So therefor you could successfully create a program that tries passcodes 5 or 10 times then tries and fails to back the iPhone up. (There is no need for a backdoor or anything fancy)
A Message to Our Customers
551–560 of 1001 posts
Re: A Message to Our Customers
#552Earlier quoted context omitted.
I'm afraid I'm too skeptical to get the same assurances as you. Apple accuses the FBI of playing language games with the term "backdoor", but I think Apple has done the same. The fact that they can push weak OS updates to a locked phone is the backdoor . This means that they can already comply with the court order, and they likely will. This letter covers them from PR damage.
I found this article about this [1] to be rather enlightening. 1) http://blog.trailofbits.com/2016/02/17/apple-can-comply-with...
[deleted]
Re: A Message to Our Customers
#553Earlier quoted context omitted.
No. The word "remote" is not applicable to an attack that only works with physical possession of the device. As far as I'm aware there is no known technique to prevent someone with physical access, a bunch of engineers, and the code signing keys from replacing firmware.
"locked" is a relative term. Anything encrypted can be broken with enough effort. But that is the semantic difference between leveraging a back door and brutally busting open the front door. I want a device where there is no back door. I hope you can appreciate that difference.
The iPhones with an A7 or later CPU should be secure against this. This whole thing is only an issue because the phone in question is an iPhone 5C, which uses an older CPU without the "secure enclave" system.
Re: A Message to Our Customers
#554Earlier quoted context omitted.
It's stated very clearly that they can push an update to an already existing device that would make it possible to retrieve "encrypted" data from said device. If the data was truly encrypted, the concept of pushing an update or creating a master key would not be possible.
That doesn't sound all correct. Assuming the phone holds an encryption key that can read/write local data, a software update could simply command it to decrypt all data and save it as a copy.
A device containing an encryption key that's just protected by a software password check would be absolutely useless. Part or all of the encryption key (maybe even the IV) is derived from the phone passphrase, this is why you can't just pop the NVRAM off a phone and try to find the key.
Re: A Message to Our Customers
#555I'm clearly in the minority here, but I don't really understand Apple's position here, nor do I understand why everyone is rallying behind them. Apple built hardware which was not particularly secure. The software defaults to a four-digit PIN. They attempt to mitigate this by adding an escalating interval between entries, and by optionally wiping the phone after too many failed tries, but this is not set in stone and…
> The government isn't even asking them to crack the phone, they just want Apple to remove the limits so the government can try to brute force it. They're even paying Apple for their trouble.
Well this exact thing isn't THAT big of a deal but it's a slippery slope. If Apple agreed to this then what else can the government ask them to do under the banner of "public safety"? And if Apple were to give the government an electronic way to brute force the touch codes, it would break the trust of every iPhone owner.
Re: A Message to Our Customers
#556Earlier quoted context omitted.
There's a huge distinction between Google (Android) and Apple (iOS) though: Apple affirms they don't have your keys, and this case bears that out (else the FBI would obtain the keys via subpoena to Apple rather than asking the court for a circumvention tool). Google is ambiguous about whether they have your Android keys; they claim they don't, however if you forget your device password it is possible to unlock your d…
> For either company to unlock the device without the owner’s permission the smartphone or tablet must not be encrypted, according to the report.[0] [0] http://www.theguardian.com/technology/2015/nov/24/google-can...
From your link:
"The situation is different for Android. Google’s version of Android, which runs on most Android smartphones and tablets in the western world, only implemented encryption by default with the latest version Android 6.0 Marshmallow released in October 2015."
That version of Android is only on a handful of devices, not even a full percentage point of global market share. Even on Lollipop and older devices that do support encryption, it has to explicitly be turned on by the user. And once again, Google is not expressly clear that they don't have your encryption keys on Lollipop and lower; they only claim not to have them for Marshmallow devices. They definitely have the keys to your encrypted data on their servers no matter what, which can include complete backups of your device.
Re: A Message to Our Customers
#557Apple should be more clear that this is 5C and not the latest version.
Re: A Message to Our Customers
#558I'm clearly in the minority here, but I don't really understand Apple's position here, nor do I understand why everyone is rallying behind them. Apple built hardware which was not particularly secure. The software defaults to a four-digit PIN. They attempt to mitigate this by adding an escalating interval between entries, and by optionally wiping the phone after too many failed tries, but this is not set in stone and…
Is it possible to update a phone without the user accepting the change (with the phone locked)? Do you want such a tool (the one the removes the security of updating) to exist so that anyone with physical access can replace the OS with something else?
Apparently it is possible to update older phones like this. On newer ones, the OS in general is not an issue, since the security bits are handled by the secure enclave. I'm not sure what the software update policy is (it's only briefly mentioned in Apple's iOS security paper) but I'd wager that it's impossible to push an update to the secure enclave software without either unlocking it or erasing the crypto keys.
I don't understand what you're getting at with the "tool" question. Nobody's talking about building something that lets anyone with physical access replace the OS. The phone's secure boot system will still require updates to be signed by Apple. Apple can replace the OS with physical access. On older hardware, it seems they can do this without wiping the data. Do I want Apple to be able to do this? It doesn't matter what I want, the fact is that they can. Since they can, and since the FBI has a court order, I don't see what's wrong with requiring them to do so. If you don't want them doing this to your phone, buy a newer one with the more secure hardware.
Re: A Message to Our Customers
#559Can someone explain this to me: if the data is encrypted, how does switching the operating system out enable one to read the data? I'm a layman in this area but I can only surmise that the data is stored unencrypted and it's the operating system itself that's somehow locked. If a change of operating system can open up encrypted data, then what's the point of encrypting hard drives or data sent over a network?
Re: A Message to Our Customers
#560Earlier quoted context omitted.
I wish people would stop lumping Apple with Google/Facebook with regards to privacy. Apple has implicitly for a long time, and lately much more vocally, cared about privacy. They don't have the same data-driven business model that Google and FB do.
> Apple has implicitly for a long time, and lately much more vocally, cared about privacy. They say that. But with closed source software we can't verify that it's true. I'm not saying they don't care about privacy, only that we don't really know if they do or not.
With open source software, it doesn't appear that people can verify things are safe either given the long-term security issues with things like OpenSSL et al.