I am happy AAPL is taking this stance. But I can't help but believe that is has very little to do with liberty, and very much with the bottom line. Either way, I guess we should be grateful for little mercies.
A Message to Our Customers
421–430 of 1001 posts
Re: A Message to Our Customers
#422Earlier quoted context omitted.
"there's no way to make repeated attempts more computationally expensive" That's not true actually. For example, the industry standard for storing passwords on a server (bcrypt) is specifically designed to slow down password match attempts.
It is true. You're confusing making _repeated_ attempts progressively more expensive with making all attempts more expensive to start with
Ah yes. You are right, I was confusing those two things. Thanks for the clarification!
Re: A Message to Our Customers
#423If I were Cook, I'd draw a line in the sand. If we are force to comply, we exit the phone business, because we won't make phones that compromise our customer's security. But that would take more balls than anyone left here in this "Land of the free and home of the brave" seems to have left anymore.
http://www.commondreams.org/news/2014/04/17/lavabit-company-...
Thank you, and I'm proud of Lavabit. They're at the top of my Balls list now.
Re: A Message to Our Customers
#424What's all this talk about pushing updates to locked phones? I have to get involved every time there's an OS update for any of my iDevices. That damn red dot on Settings.app just stares at me while I try to find a time I'd like to be without my device for half an hour.
Re: A Message to Our Customers
#425Earlier quoted context omitted.
This limitation must be built into security hardware used by iPhone so software couldn't do anything about it. I was under impression that it's how iOS security model works. If it's not and in fact this check implemented in iOS itself, it's much weaker protection and it's really looks like an intended backdoor from Apple.
It sounds like it is built into hardware with newer iPhones containing the secure enclave, but not for an older phone like the iPhone 5C.
It's not really built into ‘hardware’, it's enforced by the Secure Enclave, which is software-based and accepts software updates signed by Apple. It's secure against kernel exploits and third-parties, but not against Apple.
Re: A Message to Our Customers
#426Apple's encryption appears to be done in such a way that government entities can safely use them as well as "consumers." But what may happen, is that Apple will be force to produce 2 kinds of iPhones. One for consumers, with strong encryption, but a "backdoor" for warrant "cough" based access. 2nd type of iPhones for government use (string encryption, no backdoors)
They may already have this in place now, but what we are seeing now is a show. They are testing how people/consumers are going to react to this situation. Out government probably figures that nobody will care in the end.
In the USA, we have lost our liberty. It's time to wake up and see what is happening. It's getting worse & the people within our government are working hard to enslave us even more.
Re: A Message to Our Customers
#427Earlier quoted context omitted.
Nope. If the attacker (Apple in this case) can replace the OS, they will just do so before the phone gets wiped—replacing the OS will remove that wipe feature.
Not if the check and wiping is done in hardware as claimed by Apple for newer devices than the one in question here.
Secure Enclave is not really ‘hardware’; despite being isolated from the main OS and CPU, it is still software-based and accepts software updates signed by Apple.
Re: A Message to Our Customers
#428I see a lot of people saying they're impressed, admired, etc. at Apple for doing this. It's not about giving props: Apple is not doing this out of goodwill, or because they believe in protecting privacy. Apple has a competitive advantage against Google/Facebook in that its business model does not depend on violating their customer's privacy. They are just exploiting that competitive advantage. Cfr. https://ar.al/note…
A man went to his local parish priest and asked "Father, is it permissible to smoke while praying?" "No, my son, when praying you should show the utmost respect and attention to God" he answered. The next day, another man asked the same priest "Father, is it permissible to pray when I smoke?" "Of course, I encourage you to make your whole life one long prayer!" was the priest's answer. So, is Apple defending rights w…
It will become obvious, I think, in the following days. If they challenge the court order and fight vigorously to have it lifted, I am willing to believe that it is about the privacy. If they give in and say, "but we really didn't want to, they made us do it", I will consider their resistance more of a PR stunt.
That story, by the way, is really nice. ;-)
Re: A Message to Our Customers
#429Earlier quoted context omitted.
Yes but like where would you nop? You can't statically analyse the code because the image is encrypted at rest (and potentially partially in ram also?)
The code which decrypts the system (and is responsible for wiping the drive on repeated failures) is definitely not encrypted. How would it be able to take the input in order to decrypt the drive.
Their security PDF says that the system has a chain of trust established, anchored at an immutable loader residing inside the chip, and each step verifies the digital signature of the next step against the hardcoded Apple CA certificate.
Re: A Message to Our Customers
#430Earlier quoted context omitted.
Nowhere in this letter they say that it's possible and it seems very carefully worded to avoid stating that. They say, if it were possible they wouldn't do it anyway. That's an important legal and moral distinction. To be fair, they could have stated it explicitly.
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.