This was his employer's phone, right? As in, it was government-owned property being used in the course of terrorism. Were they using Apple's Mobile Device Management (MDM) framework or some other form of key escrow? If not, why should Apple bail out a government entity, at the expense of its own customers and security, that couldn't even be bothered to follow best practices?
A Message to Our Customers
731–740 of 1001 posts
Re: A Message to Our Customers
#732Earlier quoted context omitted.
I don't buy it. The FBI is not trying to dictate how Apple builds their devices. They want Apple to take measures to unlock one device. How do they get from that to "[the government] would have the power to reach into anyone’s device to capture their data"? Apple seems to be saying that if the FBI can ask Apple to install special software on one person's phone, then they can ask Apple to install special software on e…
I disagree. This is all about setting precedents. Once one of the dominoes falls, it's much easier for the others to start falling as well. Apple is saying the FBI is using this law to expand their power to mandate a backdoor in all devices. If this is successful, then the FBI can mandate that all secure hardware/software companies backdoor their products. Do we roll over and let the FBI do this because "oh, this is…
Apple says the FBI is using this law to mandate a backdoor. And that's exactly what I don't buy. The FBI's demand here is merely to use an existing security hole, which Apple created.
I simply don't see the leap from "this device is insecure, pleas unlock it for us" to "all devices you make must be insecure."
Re: A Message to Our Customers
#733Actually, someone other than Apple is already able to do the requested things in the court warrant (brute force passcode from a locked iPhone) - ih8sn0w has an iBoot exploit for A5 chipset (same as iPhone 5c), so he can probably boot an unsigned kernel, and use some public tools already published to crack the said passcode. If some lone hacker can do it don't be fooled for a minute that NSA can't, or that the feds couldn't buy something similar from another hacker. This is Apple covering their P ass from the press.
Re: A Message to Our Customers
#734Privacy is obviously the foremost issue at hand with the Government's request here, but there is also a huge potential impact on the future of the iPhone software. There is a huge difference between granting access to a user's data at the Government's request vs demanding a customized build of the iPhone's OS. Imagine the long-term implications of having a third-party tether its misaligned feature requests to every OS update that the iPhone makes. What would be the continued relationship with Apple and the agency behind this? Would this evolve into something analogous to HIPAA compliance?
Re: A Message to Our Customers
#735This is all brave talk until they publicly say the same thing to China, until then this political bluster. http://qz.com/332059/apple-is-reportedly-giving-the-chinese-...
Re: A Message to Our Customers
#736Earlier quoted context omitted.
As I understand it, if the code running in the "secure enclave" (containing the private keys) is ever upgraded, the hardware side intentionally deletes the private keys as part of the upgrade, whether the upgraded code would want it to or not.
Dan Guido just tweeted otherwise: https://twitter.com/dguido/status/699992079594864640
The reasoning there is far from conclusive. The argument is that the secure enclave has been updated in the past (to lengthen enforced delays) without wiping user keys.
However, without more information, this does not tell us whether it is possible in this case. The obvious implementation for a secure enclave resisting this sort of attack is to only allow key-preserving updates when already in unlocked state (which would be the case for any normal user update). All other cases should destroy the user keymat, even if the update is validly signed by Apple. This would be done by the hardware and/or previous firmware before it loaded the new firmware so you can't create an update that bypasses this step.
If this isn't how the secure enclave works now, I'll bet it will be in the next version (or update if possible).
Re: A Message to Our Customers
#737Earlier quoted context omitted.
It's not just PR. It's actually really hurting their company. Weaker security means less data can be stored on the iPhone which means less need for it, which means fewer sales.
Thank you for answering one of my questions: "Why does a multi-billion-dollar company give one lick about personal freedom ?". Companies exist to make money, not to protect our rights. It even crossed my mind that the possibility that NSA et. al. rooted these devices long ago, and that this whole "debate" is just a staged thing to make it appear as though we had any privacy and feigned adherence to the democratic pro…
Apple is also looking to foster growth in foreign markets. That's likely going to take a hit if the U.S. Government has special access to the phone.
Re: A Message to Our Customers
#738Wow this made my day. I think my faith in Apple's privacy concerns got a much needed revitalization. Privacy and encryption are the number one reason I stick with iPhone and Mac with File Vault. It was always hard to completely trust them after PRISM. However, that was arguably a different Apple. This stance against the government come poetry reaffirms my faith in the genuineness of Apple'e encryption efforts and Tim…
If this is your main reasons to choose a OS you clearly should use Linux then ;)
I prefer FreeBSD :)
No code from [redacted] makes it an excellent choice for the privacy conscious.
I use Slackware in the cases where I need a Linux kernel. I think that might give you an idea of what I'm trying to avoid. [redacted]
Anyways, I use *BSD daily in VMWare Fusion for any development that isn't related to iOS. I also do my email and web surfing in OS X because it's simply more pleasant.
Re: A Message to Our Customers
#739Earlier quoted context omitted.
One way around that is for Apple to make it extremely costly for courts to issue many of such orders, because after all Apple are free to charge whatever they like for doing this service.
The the court says "lol, make it default then". It doesn't matter how much they charge, when courts can override the decision. What apple needs to do is invalidate any way for this to happen.
The court can't make an order that a third party is not allowed to recover (valid) expenses in complying with a court order (if it gets to the point that this becomes so ordered).
Re: A Message to Our Customers
#740Earlier quoted context omitted.
> Apple, if they chose to, can make a version of iOS that disables security features and encryption and load it onto existing phone even though the phone is locked and encrypted? As I understand it, the FBI wants Apple to create a version of iOS that would disable the current feature where the data is deleted after more than 10 failed passwords attempts. This would allow the FBI to brute force the password.
That doesn't explain how they would get the update on to a locked and encrypted device, even if it existed.
They want to use DFU to build a version that is loaded into RAM and run from RAM rather than Flash.