Showing posts with label apple. Show all posts
Showing posts with label apple. Show all posts

19 February 2016

Choosing sides in the FBI-Apple dispute: who has the better argument?

Many people know my interests are at the intersection of the law and technology, and as a result, have asked my opinion on the merits of the FBI-Apple dispute. In large part because there was a lot of misinformation about the basic factual circumstances of the case, I wrote a short case summary here, but tried to remain neutral. Even as I wrote it, I really had no sense of which side had the better argument. I'll also add the obvious here, because sometimes it is not as obvious to others as it is to me: this is only my personal opinion and not work-related. It's worth what you've paid for it. I'll happily (ok, perhaps not happily) acknowledge I am wrong if the results come out contrary to my opinion.

On the other hand, most people in the tech and infosec communities chose sides in the FBI-Apple dispute pretty quickly. I was initially surprised that people's views were split as much as they were, even if it appeared (and still appears) that the split leans in favor of Apple (which is admittedly anecdotal evidence on my part). Upon further review, I am not surprised that views are as split as they are.

I took a lot longer to decide precisely because I am acutely aware of the nuances that often get lost in 140-character tweets or Facebook updates. In the end, from both my personal perspective and also what I think will actually happen, I think the FBI has the stronger argument. Apple is likely to draw out the process, but I think they will ultimately lose (although, speculating ahead, their best chance of winning may be at the Ninth Circuit if the case gets that far).

My decision is based upon the specific text of the Magistrate Judge's order, especially because it overcomes some of the more potent claims about what Apple is being asked to do. In an article entitled, "Why Lawyers Need to Stand By Apple" (which I cite because it was written by a lawyer addressed to other lawyers), we can see an example of what is being said about the case:
[Apple] is being ordered to create a master key to hack any iPhone on the planet.
Such an order is well beyond the scope of reason, and what the court is demanding Apple to do will ultimately undermine any hope of any of us ever having any privacy in the digital age.
This is not an exaggeration.
[Once Apple] creates the tool to break the encryption of any iPhone, that tool will be used again and again.
Emphases are mine. This is the core argument of the article. And it is disappointingly inaccurate. 

According to the court order, 
The court is requiring Apple to "provid[e] the FBI with a signed...Software Image File ("SIF") that can be loaded onto the SUBJECT DEVICE.... The SIF will be coded by Apple with a unique identifier of the phone so that the SIF would only load and execute on the SUBJECT DEVICE.
The court also gives Apple the option to do all of this at an Apple facility; meaning they could assist the FBI with this particular phone and then destroy the SIF without it ever being in the hands of the FBI or without ever leaving Apple's facility.

Could the FBI steal the SIF? Yes, but it wouldn't work on another phone without modification that it appears the FBI is not capable of doing. And if anyone ever found out that the FBI stole it, it is my belief no one would ever cooperate with the FBI again under similar circumstances, court order or not.

Neither would the SIF "break the encryption of any iPhone," or even this particular iPhone. This case doesn't really even have anything to do with encryption. The SIF would bypass or degrade software measures in place to prevent the auto-erase function from working, and from introducing delays after incorrect passcode attempts. It is true that even if and when Apple destroys the SIF, it will then still have actual knowledge of how to bypass these features--but do you really believe Apple doesn't already know? As others have pointed out, what they are being asked to do is already technically possible. They're not being asked here to do the impossible.

Using phrases like "this is not an exaggeration" does not grant your claims immunity from being exaggerated. In this case, it's worse than that: they're just not accurate. Moreover, words like "backdoor" are designed to elicit a certain response. The word has very negative connotations that , quite honestly, poisons the debate. Most infosec folks who hear the word "backdoor" will oppose it on its face.

I also recognize that this article doesn't represent everyone's views who is siding with Apple. I chose it partly because of it's outlandish claims and partly because I believe it captures a general perspective of how many people feel (even if not agreeing on the specific details).

You might also notice that I didn't discuss the Fourth Amendment in this blog post. There's a very specific reason why: the key issue in this case has nothing to do with the Fourth Amendment. The day after the shooting, the FBI sought and received a search warrant for a black Lexus. Pursuant to this search warrant, the FBI recovered an Apple iPhone 5C that was assigned to Farook but owned by his employer. The employer gave consent to the FBI to search the phone. So the FBI already has the consent of the phone's owner to search it. Likewise, Apple has no privacy interest in the phone. Anyone discussing this case as a Fourth Amendment issue should go back to law school or stop talking about it.

Let me last address the argument about "creating a dangerous precedent."  That may, or may not, be true. Generally speaking, decisions at the District Court level don't hold a lot of weight as legal precedent (and this is just a Magistrate Judge's decision--not even an Article III federal judge). Yes, if this case were to make it up to the Ninth Circuit (or even the Supreme Court), it would have precedential value. But that argument is circular. Any case that is not squarely on point with another previous case will quite possibly have some value one way or another. That may be a policy argument, but it's not a legal one.

What remains clear from a legal perspective is that Apple has complied (at least) 70 times with court orders for technical assistance (presumably under the All Writs Act, but not necessarily clear from this transcript). The red meat in this case is whether Apple's technical assistance under specific facts of this case are an unreasonable burden to Apple. In those 70 cases, Apple already had the technical ability to extract information from older iPhones even while they remained locked. In this case, the iPhone 5c has additional security measures that would prevent Apple from cooperating in the same way. In one sense, the additional hurdles to cooperation are self-generated on Apple's part (which is good for Apple's customers, of course--no one would argue otherwise). The difference between those 70 cases and this one is an existent technical capability to extract information from a locked phone (which no one has seriously argued against) versus the unrealized, but technically possible capability to reduce the security measures on this particular iPhone so that the FBI can brute force the passcode. It's clear to me that the burden on Apple is greater now than it was for any of those previous 70 cases. But is it unreasonably burdensome? I believe, given the situation I described above, that a court will find it to not be such a burden. As a result, from my personal perspective and also what I think will actually happen, I think the Government has the stronger argument. Apple will be forced to cooperate.

Whether you agree or disagree--and I know many of you will feel strongly one way or another--feel free to comment or tweet. If you have a question that you're curious about that I haven't addressed--ask it. Free and open debate in a wide-ranging marketplace of ideas makes us a better place--regardless of which side you come down on.

17 February 2016

Law in Plain English: Understanding the FBI-Apple dispute in 250 words or less

CaseIn the Matter of the Search of an Apple iPhone Seized During the Execution of a Search Warrant on a Black Lexis IS300, California License Plate 35KGD203, No. ED 15-0451M (February 16, 2016)

Summary: After Syed Farook and his wife Tashfeen Malik shot and killed 14 people in San Bernardino,California, on December 2, 2015, the FBI sought and received a search warrant for a black Lexus. Pursuant to this search warrant, the FBI recovered an Apple iPhone 5C that was assigned to Farook but owned by his employer. The employer gave consent to the FBI to search the phone, but the FBI could not affect the search because it did not know the passcode and did not want to auto-erase the phone after 10 erroneous attempts. The FBI sought a court order under the All Writs Act, a 1789 law which permits courts to issue orders compelling third parties (like Apple) to assist law enforcement in enabling a search--in this case, of the cell phone. The Magistrate Judge signed the order, which compels Apple to cooperate by providing the FBI with a signed iPhone software file that can be loaded into the phone's RAM with the ability to (1) bypass or disable the auto-erase function; (2) enable the FBI to submit passcodes to the device electronically (either through a physical device port or wireless protocol); and (3) eliminate time delays between erroneous attempts. The order gives Apple five business days to contest it if it believes it to be unreasonably burdensome. Apple's letter to its customers signified its intent to do so.

25 April 2011

iPhone location data controversy won't go away, despite no real evidence

There were two comments to my previous post about the iPhone and iPad's storage of location data that I want to address:
Anonymous said...
Except that apple is not using the location based services (which I can turn off) in this case, but instead is using cell phone tower triangulation that I can not turn off.
I did not agree to that !!!!!!
Anonymous said...
It says "real-time location data". This does not address access to historical location data, which is different.
...and, like the previous reply said, you can't actually turn off the tower triangulation unless you turn the phone off.
Indeed, there is evidence that turning off location services does not actually stop the storage of such information.  Hopefully, Apple will address this issue very soon, especially considering that using the term "location services" implies more than just GPS, and presumably includes cell tower triangulation data. Still, as I stated in the previous post, the storage of this data is expressly contemplated in the licensing agreements.  The second comment, which suggests that "[i]t says "real-time location data". This does not address access to historical location data, which is different" is actually incorrect, as the license agreement says "...transmit, collect, maintain, process and use your location data, including the real-time geographic location..." Specifying the inclusion of real-time data does not exclude historical data, only that it is a part of a larger body of data.

The bigger issue are the allegations that the "iPhone sends your location to Apple twice a day." Despite this blog post and some rather sensational news reporting of this issue last week and throughout the weekend, no one has actually been able to produce a shred of data that suggests this is true.  While no one can prove a negative, @Dakahuna2007 captured 24 hours of his iPhone's traffic this weekend and found no such "phone home" evidence.

In closing, I'll ask the same question I asked last week: Does anyone actually have a capture file showing location data being transmitted to Apple, or are we just repeating unsubstantiated rumors?

20 April 2011

Outrage over storage of Apple location data is misplaced

The infosec community is outraged today that iPhones and iPads are storing location data. Headlines proclaim the travesty: iPhone and iPad 3G caught keeping secret location tracking database andiSpy Conspiracy: Your iPhone Is Secretly Tracking Everywhere You've Been. Two researchers developed an open source application that plots this location data on a map.  I too would be outraged, except for the fact that Apple's licensing agreements for the iPad and iPhone expressly address this issue:
(b) Location Data. Apple and its partners and licensees may provide certain services through your iPad that rely upon location information. To provide these services, where available, Apple and its partners and licensees may transmit, collect, maintain, process and use your location data, including the real-time geographic location of your iPad. The location data collected by Apple is collected in a form that does not personally identify you and may be used by Apple and its partners and licensees to provide location-based products and services. By using any location-based services on your iPad, you agree and consent to Apple's and its partners' and licensees' transmission, collection, maintenance, processing and use of your location data to provide location-based products and services. You may withdraw this consent at any time by not using the location-based features or by turning off the Location Services setting on your iPad. Not using these features will not impact the non location-based functionality of your iPad. When using third party applications or services on the iPad that use or provide location data, you are subject to and should review such third party's terms and privacy policy on use of location data by such third party applications or services.
 Note that the iPhone agree is virtually identical. The text in bold is Apple's emphasis.

Now I'll be the first to admit that I don't read terms of service and licensing agreements. Very few people do, but the failure to do so doesn't give you a free pass to complain. Ignorance of service agreements does not justify moral outrage. You suck it up and admit to yourself that you didn't read it, and move on.

04 March 2010

Apple #FAIL in the App Store

Yesterday came news from Apple and app developers that WiFi scanning apps were being banned from the App Store. The reason? "[U]sing private frameworks to access wireless information," which seems to be code for anything that is using the iPhone's 802.11 radio. Any of these such apps have been removed, including WiFiTrak, WiFiFoFum, yFy Network Finder, WiFi-Where, WiFi Get and WiFi Get Plus. It is interesting to note that among them, WiFiFoFum has been available on the App Store since September 2008.

To me, this means either that 1) Apple's security process is incredibly flawed (having an allowed an app that used a "private framework" since 2008); or more likely 2) it's not about security at all, and more about DRM, control and changing the rules at their own whim (which, frankly, also says a lot about their security process).

I don't have my phone with me at the moment, but I am assuming that any such apps already installed should continue to work (I have read about the rumored Apple remote kill switch for apps, but that they have apparently never actually used it). As a result this will just add momentum to the reasons to jailbreak; the developer of yFy Network Finder has signalized his intent to make his app available on Cydia.

I'm gonna go out on a limb here and say that Apple probably won't be refunding money to the people who paid for these apps, either.

#FAIL

15 August 2005

IPodLinux update

A while back (here, I posted my experiment with running Linux on my IPod. Here is what I wrote:
Here are some problems I encountered:

1. Playback was a different story. I chose a few songs at random: some played ok, others played too fast, some played with significant delays and static, some didn't play at all. Seems like none of my "Purchased" music plays correctly. I either get a "malloc failed" or the song tries to play in mono and all I get is static.

Are playback issues related to the overall quality of the MP3? I have no idea.

2. Also, I haven't had luck using the rewind/fast-forward buttons while a song is playing, i.e., you can't use the fast-forward button to skip ahead or goto the next song.

3. Further, when one song ends, it just returns to the song selection list rather than playing the next song.

4. The power meter showed full in Linux despite the fact that the battery was nearly dead. Rebooting to Apple showed correctly, an almost dead battery.

I didn't go too much further, but I was hoping I could perhaps find solutions to these issues. Alas, I did not. So I updated the Apple firmware which restored the original configuration.

04 March 2005

IPodLinux

My IPod now dual-boots both the original Apple firmware and IPodLinux.

http://sourceforge.net/projects/ipodlinuxinst/

http://forum.defcon.org/showthread.php?p=58864#post58864

I have a third generation IPod, a 15GB model and I figured what the heck so I installed IPodLinux on it.

I first connected my IPod and waited until it updated. After that was complete, I downloaded the (Windows) installer program, unzipped to a temp directory, and ran ipodlinux-installer.exe.

It searched for and downloaded the updated kernel. I chose linux as the default boot (it leaves the original apple firmware intact and can be uninstalled without problems).

At this point it will prompt you to close ITunes or whatever else is connected to the IPod. It then installs Linux and took all of about 15 seconds or so on my computer.

When it's finished, it asks you to disconnect your IPod, upon which it should (and did) reboot. If it doesn't, holding menu and play for 5 seconds will manually reboot.

Upon the reboot, the familiar apple logo shows, followed by the familiar Penguin logo. After that, the screen scrolls quickly as Linux boots up. A few seconds later, your new Podzilla menu is loaded. To load the non-default, reboot and hold the rewind button. The apple logo will appear, followed by the Penguin, and then instead of scrolling through the Linux boot-up, the "normal" Apple firmware loads.

Here are some problems I encountered:

1. Playback was a different story. I chose a few songs at random: some played ok, others played too fast, some played with significant delays and static, some didn't play at all. Seems like none of my "Purchased" music plays correctly. I either get a "malloc failed" or the song tries to play in mono and all I get is static.

Are playback issues related to the overall quality of the MP3? I have no idea.

2. Also, I haven't had luck using the rewind/fast-forward buttons while a song is playing, i.e., you can't use the fast-forward button to skip ahead or goto the next song.

3. Further, when one song ends, it just returns to the song selection list rather than playing the next song.

4. The power meter showed full in Linux despite the fact that the battery was nearly dead. Rebooting to Apple showed correctly, an almost dead battery.

My initial verdict is that IPodLinux is fun to play around with and test out, but if you want to be able to play all of your songs without problems, boot to the Apple firmware. I plan to keep playing around with it to hopefully discover what might be causing the playback problems...stay tuned.

Feel free to email me or ask any questions.