Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Privacy Communications Encryption Handhelds Iphone Security Apple Your Rights Online

Apple's iPhone Already Has a Backdoor 401

Nicola Hahn writes: As the Department of Justice exerts legal pressure on Apple in an effort to recover data from the iPhone used by Syed Rizwan Farook, Apple's CEO has publicly stated that "the U.S. government has asked us for something we simply do not have, and something we consider too dangerous to create. They have asked us to build a backdoor to the iPhone." But, as one Windows rootkit developer has observed, the existing functionality that the FBI seeks to leverage is itself a backdoor. Specifically, the ability to remotely update code on a device automatically, without user intervention, represents a fairly serious threat vector. Update features marketed as a safety mechanism can just as easily be wielded to subvert technology if the update source isn't trustworthy. Something to consider in light of the government's ability to steal digital certificates and manipulate network traffic, not to mention the private sector's lengthy history of secret cooperation. Related: wiredmikey writes: Apple said Monday it would accept having a panel of experts consider access to encrypted devices if US authorities drop efforts to force it to help break into the iPhone of a California attacker. Apple reaffirmed its opposition to the US government's effort to compel it to provide technical assistance to the FBI investigation of the San Bernardino attacks, but also suggested a compromise in the highly charged legal battle.

In his first public remarks since Apple CEO Tim Cook said he would fight the federal magistrate's order, FBI Director James Comey claimed the Justice Department's request is is about "the victims and justice."
This discussion has been archived. No new comments can be posted.

Apple's iPhone Already Has a Backdoor

Comments Filter:
  • Tim Cook's letter (Score:5, Informative)

    by Midnight Thunder ( 17205 ) on Monday February 22, 2016 @12:09PM (#51559397) Homepage Journal

    In the context of this article it is worth pointing out the letter that Tim Cook sent out to Apple employees:

    http://arstechnica.com/tech-po... [arstechnica.com]

    I believe he makes good points, and where ever we end up, it should be because of proper discussion understanding implications, rather than because 'Apple is evil' mantra, that will end up burning everyone.

    • Re:Tim Cook's letter (Score:5, Interesting)

      by Anonymous Coward on Monday February 22, 2016 @12:44PM (#51559783)

      From the arstechnica article:

      The document closed with a call for Congress to "form a commission or other panel of experts on intelligence, technology, and civil liberties to discuss the implications for law enforcement, national security, privacy, and personal freedoms. Apple would gladly participate in such an effort."

      From the leaked White House memo linked in the Counterpunch article:

      Proposed Policy Principles
      Deputies agreed that attempts to build cooperation with
      industry, with advice proposing specific technical solutions, will
      offer the most successful option for making progress on this
      issue. In particular, given industry and civil society's
      combative reaction to government statements to date, any
      proposed solution almost certainly would quickly become a focal
      point for attacks and the basis of further entrenchment by
      opposed parties. Rather than sparking more discussion,
      government-proposed technical approaches would almost certainly
      be perceived as proposals to introduce “backdoors” or
      vulnerabilities in technology products and services and increase
      tensions rather build cooperation.
      However, if the United States Government were to provide a set
      of principles it intends to adhere to in developing its
      encryption policy, such a document could spark public debate.

      Proposing such principles would not be without risk, as some
      constituencies may not distinguish between principles and
      specific technical approaches. As a result, these principles
      could come under attack, but could also serve to focus Public or
      private conversation on practicalities and policy trade—offs
      rather than whether the government is seeking to weaken
      encryption or introduce vulnerabilities into technology products
      and services.

      It seems like the plan is proceeding nicely. We getting into the "public debate" phase. Soon it will move on to the trade-off phase decided on by a panel of private and governmental experts.

      • by FlyHelicopters ( 1540845 ) on Monday February 22, 2016 @02:42PM (#51561035)

        It seems like the plan is proceeding nicely. We getting into the "public debate" phase. Soon it will move on to the trade-off phase decided on by a panel of private and governmental experts.

        Yea, but part of the challenge is that not everything in the world can be "compromised" or "traded-off".

        Encryption either works or it doesn't. Your info is either secure or it isn't. If the government can access it, then it isn't secure.

        There just isn't any give-and-take here, either you can make your info private, or you cannot.

      • by kheldan ( 1460303 ) on Monday February 22, 2016 @04:40PM (#51562171) Journal
        Encryption, by it's very nature, is a binary issue; it either 'works' or it 'doesn't work', there is nothing in between. If you design in a work-around for not having the keys, then the encryption 'doesn't work' because it can be defeated. If you make the front door and it's framework out of quarter-inch thick hardened steel armor plate and secure it with an Abloy lock, but then have a spare key under the Welcome mat, you've failed to properly secure your house. If you have a secret and you share it with someone else, it's not a secret anymore. There is no such thing as 'a little pregnant', you either 'are' or you 'are not'. So it goes with encryption: Either 'encryption==TRUE' or 'encryption==FALSE', there is no state between the two. Even if they banned ALL encryption, it won't accomplish what they want to accomplish; criminals and terrorists will still use encryption of some sort or other, it's commonly available now -- and they won't have any 'backdoor' into that, either! The entire subject is moot. What law enforcement and the government wants is pointless and stupid and they need to just GIVE UP and forget about it. If they can't suss out what criminals and terrorists are doing using conventional investigative methods then they're incompetent and need to be replaced with people who can.
    • by Tablizer ( 95088 ) on Monday February 22, 2016 @01:28PM (#51560257) Journal

      I especially like this quote:

      "...we strongly believe the only way to guarantee that such a powerful tool isn't abused and doesn't fall into the wrong hands is to never create it."

  • by mlw4428 ( 1029576 ) on Monday February 22, 2016 @12:11PM (#51559405)
    I hate Apple as much as the next anti-Apple-fan boy, but come on. Literally EVERY OS has this concern. I wouldn't call it a backdoor anymore than I would suggest that having a window not made out of bulletproof glass is an open invitation for robbers into your house. In other words, this is sort of like "duhhhhhhh" material and hardly newsworthy. Now having an open and honest discussion about the security of update services for OS and the security methodologies employed, would be a fantastic article.
    • by ceoyoyo ( 59147 ) on Monday February 22, 2016 @12:14PM (#51559445)

      Every OS does not have that problem. I'm not even sure that iOS does. It's possible Apple has a way to forcibly push an over the air OS update to your phone, but I don't recall ever hearing any confirmation of that. As far as non-mobile OSes, the only one I've ever heard about forcing updates on you is Windows 10.

      • Fair enough. I should have said systems configured to automatically update -- which Linux, Windows, OSX, and so on can do. I will grant that on Linux and perhaps on Mac OSX it is opt-in (not sure on Mac...) and on Windows it is opt-out. But the point remains valid, the attack vector exists anywhere. To elaborate on my example, it's like having Windows in your house that you can open up to let the breeze in. Some houses have them locked when you move in, others do not. Again the article would be newsworthy w
    • by xxxJonBoyxxx ( 565205 ) on Monday February 22, 2016 @12:20PM (#51559503)

      >> Literally EVERY OS has this concern

      I'm not sure you understand the concern then. The feature in question is, "ability to remotely update code on a device automatically, without user intervention"

      Windows allows you to disable automatic updates (even on Windows 10). Linux famously allows you to only put the specific code you want into your OS. (Google "compile kernel", etc.) If iPhones require automated updates or they will stop functioning, I'd say that concern is still fairly unique to the iPhone platform.

      • You can't disable updates on Windows 10, only "defer" them, at least on non enterprise versions.

        This screenshot is from my Windows 10 Pro machine at work. There is only "aplazar" available (defer)

        • Forgot the link: http://imgur.com/EPpxm3n/ [imgur.com]

        • Right, you can only defer them.

          Except that you never really had the "don't install this update" on Windows 7 either. Sure, you can just choose to not install the update on 7... and it won't ever try to install it. Except, you will also never get rid of the update either unless you "hide" the update.

          Windows 10 is no different except that there is apparently no way to "hide" the update.

          But, just like with 7, you can endlessly defer the installation of an update simply by ignoring it.

          I have had an update on Wi

        • by ZiakII ( 829432 )
          You can disable the update on Windows 10 Pro/Enterprise. It's a group policy gpedit.msc -> Computer Configuration\Administrative Templates\Windows Components\Windows Update. -> Set it to not install updates.

          Or... navigate to [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] and set "AUOptions"=dword:00000002 .
    • by Anonymous Coward on Monday February 22, 2016 @12:21PM (#51559517)

      I think the article is not correct. iOS doesn't let you run an update that reboots the phone unless you input the password first (ostensibly to prevent you from being locked out on reboot).

      I think Apple can force load a new OS without this limitation, but it needs physical access to do so.

      • by zerosomething ( 1353609 ) on Monday February 22, 2016 @01:30PM (#51560287) Homepage

        I think the article is not correct. iOS doesn't let you run an update that reboots the phone unless you input the password first (ostensibly to prevent you from being locked out on reboot).

        I think Apple can force load a new OS without this limitation, but it needs physical access to do so.

        Exactly correct, the article is wrong on the fundamental premise that Apple can force an over the air update. They, or anyone, can force a firmware update when connected to a wire. The Government want's Apple to create firmware that would turn off the security option in iOS that wipes the phone after 10 failed passcode attempts.

    • I hate Apple as much as the next anti-Apple-fan boy, but come on. Literally EVERY OS has this concern. I wouldn't call it a backdoor anymore than I would suggest that having a window not made out of bulletproof glass is an open invitation for robbers into your house. In other words, this is sort of like "duhhhhhhh" material and hardly newsworthy. Now having an open and honest discussion about the security of update services for OS and the security methodologies employed, would be a fantastic article.

      Yeah sure, no problem. Then, having confirmed that they can do this they get an endless stream of secret 'national security letters' and iphones for them to break into.

    • Literally EVERY OS has this concern.

      Secure credential storage doesn't have this concern because its firmware can't be updated (at least not without first successfully authenticating). iPhones have secure credential storage, both inside their cryptographic processor and inside their SIM cards. So it is hard to understand why iPhones have this vulnerability at all. It's either a big screw-up or deliberate.

      Even without secure credential storage hardware, you can still make PIN numbers reasonably secure aga

      • Ehh, who needs mod points.

        Take a look at this link: https://www.techdirt.com/artic... [techdirt.com]

        The gist is that iPhone's "Secure credential storage" firmware is part of the regular firmware, and can be updated without authentication. It just has to be signed by Apple. I will agree that a much better model would be a fully seperate chip that requires authentication, or a wipe to update the firmware. Unfortunately, it looks like Apple didn't want to do things properly.

        I'm not sure what you're talking about for the

    • Re: (Score:2, Informative)

      by friedmud ( 512466 )

      There is no vulnerability here. There are no such thing as "automatic updates" of iOS. There are "auto-downloaded" updates... but you ALWAYS have to install them manually... and to do so you need to unlock the device AND put in your iCloud username and password.

      There is NO backdoor here.

      • You must have missed all of those FACTS stating otherwise. Apple has confirmed that they CAN do what the DOJ is asking, but they don't WANT to because they feel, and I would agree, that it sets an extremely dangerous precedent. I haven't seen any definitive information indicating whether the update can be done OTA or must be done via a USB cable and booting into a low level mode. Either way, the fact that a device can have it's software and/or firmware updated without user intervention is a security hole,
        • No: What's been stated is that if Apple is in physical possession of the phone they can put the phone in a special mode and forcibly update portions of the operating system.

          This is not an issue with the normal system that's built in that people use to update their operating system.

          However, I do expect Apple to close even this final loophole in the next version of iOS. Instead of encrypting just the user's data on the phone... EVERYTHING will be encrypted... including the OS.

        • by mark-t ( 151149 )

          Apple has confirmed that they CAN do what the DOJ is asking

          Citation?

    • My OS only updates when I want it to. Cyanogenmod comes built that way. Some danger from Google Play or Amazon App Store, which can install whatever they want.

      Security is hard. I can still install a bad application, or have Google Play update itself with nastiness; I can also remove those things and not install updates. It's a similar problem when the phone's whole OS has a built-in auto-update, although you can't just rip that out; then again, modified Android OSes *are* just ripping the OS out.

  • And soon it won't be (Score:5, Interesting)

    by JonahsDad ( 1332091 ) on Monday February 22, 2016 @12:11PM (#51559409)
    When I read exactly what the FBI was asking Apple to do, I realized that there was a back door, and that Apple will most likely be doing what they can to close this back door in a future iPhone release.

    If I were Apple, I'd make sure a future release gave the user the option of only allowing firmware updates after the user logged in. This doesn't have to be required for every iPhone (corporations might want this disabled on iPhones they purchase for their employees), but it should at least be an option.
    • by steve6534 ( 809539 ) on Monday February 22, 2016 @12:29PM (#51559611) Homepage
      A normal update does require you to unlock the phone to accept the update. They're talking about leveraging recovery mode which can be used to force load an image onto a phone that might be otherwise unusable. See here - https://support.apple.com/en-u... [apple.com]
      • A normal update does require you to unlock the phone to accept the update. They're talking about leveraging recovery mode which can be used to force load an image onto a phone that might be otherwise unusable. See here - https://support.apple.com/en-u... [apple.com]

        Yes. That's the exact Apple support page that worries me. It says "iTunes will try to reinstall iOS without erasing your data." Updating iOS in this way needs to either require my passcode or erase my data. I expect that it will in a future version version of hardware (because only doing it in software isn't enough).

        • by dunkindave ( 1801608 ) on Monday February 22, 2016 @01:05PM (#51560005)

          A normal update does require you to unlock the phone to accept the update. They're talking about leveraging recovery mode which can be used to force load an image onto a phone that might be otherwise unusable. See here - https://support.apple.com/en-u... [apple.com]

          Yes. That's the exact Apple support page that worries me. It says "iTunes will try to reinstall iOS without erasing your data." Updating iOS in this way needs to either require my passcode or erase my data. I expect that it will in a future version version of hardware (because only doing it in software isn't enough).

          I have gone through this process, so can speak from experience. My wife changed her passcode, then promptly forgot the new one. The only option according to Apple is to reinstall. But if the phone is previously synced to a computer, it has exchanged cookies that allow the computer to still access the phone's contents (this is one of the reasons why the FBI wanted to find that hard disk). When I did the reinstall, it first read the contents out like a normal backup, then installed a fresh OS, then restored the data from the backup. I think this is what they mean by "try to reinstall iOS without erasing your data." It does get erased, but is restored, so effectively not erased.

          About six months later she did the same thing, except this time, she tried rebooting the phone. When I hooked it to the computer, the system was unable to access the phone, so the restore could only put back the data saved during the latest backup (about a month before). She was bummed since she lives off her phone's calendar and doesn't trust it backing up to iCloud.

    • by shmlco ( 594907 )

      Also that any update of the secure enclave firmware erases the current security key. Better to make the enclave firmware flash once and not updatable.

  • by AmiMoJo ( 196126 ) on Monday February 22, 2016 @12:12PM (#51559421) Homepage Journal

    Signed updates are fine, as long as you can't update the firmware in your secure memory to alter the maximum number of wrong guesses before erasing or reduce the minimum time between guesses. That way even if the OS image is compromised you still need to enter the correct code within n attempts to unlock the device.

    It seems incredible that Apple thought it would be a good idea to build that functionality. I don't know of any other ARM CPU design that allows it, for this exact reason.

    • by sims 2 ( 994794 )

      Apple already had to update the fw once http://9to5mac.com/2015/03/18/... [9to5mac.com] because it wasn't incrementing properly when the power was cut. You would prefer to wipe the phone to apply the update?

      Personally I would like the ability to set the key myself.

      • by adamstew ( 909658 ) on Monday February 22, 2016 @03:12PM (#51561305)

        You can fix that super easily:

        secure enclave will accept software updates in two cases: 1) provide unlock code and keep the encryption key intact. 2) do not provide unlock code and then wipe the encryption key.

        This is a secure method of doing it. You can either provide the unlock code and update the firmware of the secure enclave without wiping the device, or you can wipe your device and update the firmware of the secure enclave without the unlock code.

  • Is that this will come up under free speech violations since code is speech and the government is requiring Apple to create the code and the means to do this.
    • >> this will come up under free speech violations

      You must be new here. (The nod to 'net makes me think you woke up from a nap started in 1995.)

      >> Code is speech and the government is requiring Apple to create the code and the means to do this.

      Remember that thousands of US-based governments (fed, state, county, city...) already requires thousands of companies to develop code (or "speech" if you want) and the means to do X, Y and Z (e.g., "calculate tax withholding on..." or "use GPS fencing to

    • I hope you're right, but SCOTUS says money is speech and people are still compelled to pay money.

      The issue of compelled speech is not completely settled either. The courts have ruled both that it can be and that it can't be depending on circumstances.

      http://www.firstamendmentcente... [firstamendmentcenter.org]

      https://www.washingtonpost.com... [washingtonpost.com]

      https://www.researchgate.net/p... [researchgate.net]

  • by Jawnn ( 445279 ) on Monday February 22, 2016 @12:19PM (#51559499)
    ...and that is that you should not trust the security of your stuff to a third party. Not Apple, not "the cloud", and definitely not the government. Don't get me wrong. I am not some foil hat wearing paranoid when it comes to "the government", but I damn sure don't consider them trustworthy enough to manage my crypto keys. I'd trust a handful of cloud operators before I'd trust the government, and none of them get my keys either.

    Listen up, law enforcement, DoJ, et al. I am more afraid of your incompetence than I am any dark "world domination" motive on your part, but I am nowhere near as afraid of :"teh terrorists" as I am of you, regardless of your motive. So hands off my crypto. M'kay?

  • by NicholFD ( 726973 ) on Monday February 22, 2016 @12:20PM (#51559501)
    Nicola Hahn is incorrect. No one has stated that Apple has the ability to, "remotely update code on a device automatically, without user intervention". The method the device would be updated requires DFU (Device Firmware Upgrade) mode, physical possession of the device and a USB connection to a PC/Mac: https://www.theiphonewiki.com/... [theiphonewiki.com] Way to grab a headline, though...
  • by Kjella ( 173770 ) on Monday February 22, 2016 @12:20PM (#51559507) Homepage

    What they're talking about is putting the phone into Device Firmware Update mode, like this [imore.com]. Only then will they be able to update it remotely and on the newest iPhones that'd also wipe the encryption keys. But not on the model in question here.

  • Is this why drug dealers buy lots of pre-paid phones?

    • >> why drug dealers buy lots of pre-paid phones

      It's more that pre-paid phones can be obtained with cash or pre-loaded cash cards. Regular phone plans are typically tied to a bank account (often a credit card account), which ties a specific phone to a person (that can be ID'ed through a bank), so drug dealers would prefer the "burner" route.

      In other words, arrested drug dealers don't care as much about a "ha ha you can't encrypt my data" defense as they do about "hey - that's not my phone!" defense.

      • by Vokkyt ( 739289 )

        While some of this is true, I think the real answer is even simpler: they're disposable.

        There's a reason that the phones are called burner phones; if it gets trashed or destroyed for whatever reason, you're not out anything except an easily replicated list of phone numbers.

        Likewise, a lot of burner phones just don't have many of the tattle-tale features that smart phones do; older models lack GPS, very little on-board memory for logging, and so on.

        While law enforcement certainly does have the means to spy o

  • Android (Score:5, Interesting)

    by Tokolosh ( 1256448 ) on Monday February 22, 2016 @12:21PM (#51559523)

    Lot's of good discussion about iOS and Apple.

    I would like to have the same analysis about the state of Andriod. Can it be made secure against such backdoors? Do third-party flavors and rooting have a role? Is it possible to have a device where all software and firmware code can be examined?

    • I would like to have the same analysis about the state of Andriod. Can it be made secure against such backdoors?

      Android software provides APIs for storing encryption keys in secure hardware. However, whether the secure hardware storage your phone uses is actually secure depends on the manufacturer, how they implement the hardware and what kinds of modifications they have made to the software.

      Android also provides hooks for external security devices. And you can use the SIM card for storing encryption ke

  • by Anonymous Coward on Monday February 22, 2016 @12:22PM (#51559529)

    Apple has updated the secure enclave with an iOS update in the past and added additional protection, so it presumably can do an update that would REMOVE protections on the SE. So the same scenario of this phone can theoretically be applied to any existing iPhone and not just a 5c.

    So right now, Apple is making the iPhone 7 immune to this attack vector. With the iPhone7, even Apple with not be able to do a firmware modification to the SE in DFU mode. The correct user password will *have* to be entered in the iPhone7 and it will be enforced solely in the SE hardware. There will be nothing that can get around that. You can't solder on a different SE chip, you can't swap components, change the IEMI, or anything else.

    That will be the selling point of the iPhone 7. iOS 9 was software-based protection since a software update could (apparently) change the SE. Apple will disclaim they never expected their own government trying to force them to create a hacker-version of iOS, so security of the iPhone has to be hardware based. iPhone7 will have true 100% bulletproof hardware-based protection that will truly be bulletproof. And that is what they will sell.

    Then, unfortunately, the FBI will simply demand iOS source code and signing keys.

    • Making phones immune to firmware upgrades is probably not sufficient, since a determined attacker can still load software into RAM and then boot into that. It's also not necessary to prevent the proposed FBI attack. (It's still a good idea for many other reasons.)
    • If the SE is designed correctly then even publishing the source code and signing keys will not allow recovering the encryption key.

      That's what the S stands for!

  • I don't understand what the FBI is asking for. I understand they'd like Apple to install a backdoor key for use in the future, but Apple can't add a backdoor to an existing phone which would defeat existing encryption, could it? How could they do that?

    If the FBI has the phone, then the FBI has the encrypted data, and they can brute force attack it. But if the data wasn't encrypted using a scheme with a backdoor key, and you don't have the frontdoor key, then what is Apple supposed to do exactly?

    • by NetNed ( 955141 )
      After ten failed tries an iPhone can, if turned on, which by default is not, erase all data on the phone. Have a hard time believing that terrorist that throw a hard drive in to a lake thinking it will destroy it would know this about the iPhone AND have it turned on. FBI is just using this as an excuse to get it's claws in something the easy way, and set president in forcing a private company to do it's bidding.
    • This is covered in the numerous articles on the topic.

      The FBI wants to brute force the PIN, not the encryption key. The phone is set to wipe if the PIN is incorrectly entered too many times. They want a custom firmware that will let them guess until they get the right PIN, at which point they will simply have an unlocked phone with no need to even try to brute force the encryption.

  • It'll be interesting to see how the conflict between intellectual property rights and national security is going to play out. Both issues have driven the US international policies for the last decades, at least. Both have powerful lobbies in DC.
  • What more? (Score:5, Insightful)

    by NetNed ( 955141 ) on Monday February 22, 2016 @12:26PM (#51559569)
    The cell provider gave them their info and Apple gave the FBI the last iCloud back-up for the device, so what more could they actually find on the phone that would be of such a great use? I mean, I have a hard time believing that a couple of people that think throwing a hard drive in to a lake destroys the data on it would have the info on their phone not back-up to iCloud or have used something that is only obtainable from the unlocked phone itself. Add to that the story of the phones pass code changing while in FBI possession, which would be easy to track, and that the reports were that they threw their phones in the lake too. So you can find a 18 year old downloading illegal movies, but you can't track who changed the phone's lock code?? Ahhh yeahhhh, all of it together seems like some overwhelming bullshit.
    • Re:What more? (Score:4, Interesting)

      by tlhIngan ( 30335 ) <slashdot@worf.ERDOSnet minus math_god> on Monday February 22, 2016 @01:44PM (#51560457)

      The cell provider gave them their info and Apple gave the FBI the last iCloud back-up for the device, so what more could they actually find on the phone that would be of such a great use? I mean, I have a hard time believing that a couple of people that think throwing a hard drive in to a lake destroys the data on it would have the info on their phone not back-up to iCloud or have used something that is only obtainable from the unlocked phone itself. Add to that the story of the phones pass code changing while in FBI possession, which would be easy to track, and that the reports were that they threw their phones in the lake too. So you can find a 18 year old downloading illegal movies, but you can't track who changed the phone's lock code?? Ahhh yeahhhh, all of it together seems like some overwhelming bullshit.

      Easy. The FBI has two reasons for compelling Apple to do this.

      1) The phone itself. Think of all the credentials stored on the device that you now can access. Saved messages in WhatsApp and other IM style apps, live access to various services (perhaps they used GMail? The Gmail app or web page will show you the account and its data as well), etc. etc. etc.

      Effectively, they get access to all sorts of data without requiring a warrant - perhaps they know he had a GMail account, and then they'd need to get a warrant to get information from that account from Google. But if they can access the Gmail app from the iPhone, warranty avoided!

      2) The second part is to get Apple to deveop this software, because once it exists, it can be used over and over again.

      The case cited for the All Writs Act involves the use of pen registers. The telephone company lost purely because they were already using pen registers in their day to day operations to verify billing and check for fraud. So they can be compelled to connect a pen register up to a desired phone line because they were doing it already.

      Apple doesn't have the software, but once they do, it can be compelled into action. That's the result the FBI really wants.

    • Re:What more? (Score:4, Informative)

      by Anubis IV ( 1279820 ) on Monday February 22, 2016 @02:00PM (#51560603)

      You have a few factual errors. The passcode wasn't changed. The iCloud account password was. The distinction matters quite a bit, since one is used to unlock the phone, while the other is used by the phone to access external Apple services, including iCloud Backup. The hope here was that they could initiate an automatic iCloud backup by charging the iPhone while it was in range of a recognized WiFi network. Apple has the ability to access data that's backed up to iCloud, so they'd be able to provide the FBI with the lawfully-requested contents of the iPhone if a fresh backup were initiated, and they could do so without needing to build malicious tools.

      Unfortunately, the iPhone belonged to the county (since the shooter was a government employee). For reasons that are unknown but very suspicious since the iCloud backup technique is known to the FBI and has proven useful in the past, in the day immediately after the attack, the FBI ordered the county to reset the user's iCloud password, which the county was able to do by logging into his work e-mail that was tied to his iCloud account and initiating the password reset from there. As a result, the iPhone now lacks the correct credentials to create an iCloud backup. The FBI then tried to downplay the matter in the footnote of some court documents by implying offhandedly that it was local yokels who made a mistake, until the "local yokels" spoke up in their own defense by pointing out that they were acting on FBI orders.

      So, going back to your original question, the FBI wants one thing: a change in precedent that allows them to put a stop to strong encryption. Demanding access to the current contents of the phone (despite already having a recent backup) while sabotaging the best known way to get at it is just a means to that end.

  • Specifically, the ability to remotely update code on a device automatically, without user intervention, represents a fairly serious threat vector.

    This is a core feature of most modern operating systems. It is easily disabled in both iOS and OS X.

    Your argument is only slightly less inane than suggesting that allowing a computer to access the Internet counts as a backdoor.

  • by fraxinus-tree ( 717851 ) on Monday February 22, 2016 @12:30PM (#51559613)
    iPhone has a backdoor for apple's own use. For a lot of people, it's OK as long as only Apple uses it. Even if they know about it, they understand it as a fair trade. Well, for me it is not OK but I am a minority so I work around the problem by not using i-devices.

    FBI wants to use this very backdoor, too. For a lot of people, this is already NOT OK. The government is pretty much different from a company you have business with.

    And it is not about the ability to crack. NSA probably has the resources to do that. FBI wants it "by the law".
  • by msauve ( 701917 ) on Monday February 22, 2016 @12:32PM (#51559629)
    It's obvious that the FBI doesn't have a good intellectual or legal argument, and they're now resorting to an emotional one.
  • A response (Score:5, Informative)

    by brennz ( 715237 ) on Monday February 22, 2016 @12:43PM (#51559773)
    This is all distraction, as operating system configuration and patching is not a "backdoor'.

    The best response to the FBI's request I've read thus far comes from the noted IOS forensics security guru, Jonathan Zdziarski [zdziarski.com] where he wrote the following

    An instrument is the term used in the courts to describe anything from a breathalyzer device to a forensics tool, and in order to get judicial notice of a new instrument, it must be established that it is validated, peer reviewed, and accepted in the scientific community. It is also held to strict requirements of reproducibility and predictability, requiring third parties (such as defense experts) to have access to it. I've often heard Cellebrite referred to, for example, as the Cellebrite instrument in courts. Instruments are treated very differently from a simple lab service, like dumping a phone. I've done both of these for law enforcement in the past: provided services, and developed a forensics tool. Providing a simple dump of a disk image only involves my giving testimony of my technique. My forensics tools, however, required a much thorough process that took significant resources, and they would for Apple too.

    The tool must be designed and developed under much more stringent practices that involve reproducible, predictable results, extensive error checking, documentation, adequate logging of errors, and so on. The tool must be forensically sound and not change anything on the target, or document every change that it makes / is made in the process. Full documentation must be written that explains the methods and techniques used to disable Apple's own security features. The tool cannot simply be some throw-together to break a PIN; it must be designed in a manner in which its function can be explained, and its methodology could be reproduced by independent third parties. Since FBI is supposedly the ones to provide the PIN codes to try, Apple must also design and develop an interface / harness to communicate PINs into the tool, which means added engineering for input validation, protocol design, more logging, error handling, and so on. FBI has asked to do this wirelessly (possibly remotely), which also means transit encryption, validation, certificate revocation, and so on.

    Once the tool itself is designed, it must be tested internally on a number of devices with exactly matching versions of hardware and operating system, and peer reviewed internally to establish a pool of peer-review experts that can vouch for the technology. In my case, it was a bunch of scientists from various government agencies doing the peer-review for me. The test devices will be imaged before and after, and their disk images compared to ensure that no bits were changed; changes that do occur from the operating system unlocking, logging, etc., will need to be documented so they can be explained to the courts. Bugs must be addressed. The user interface must be simplified and robust in its error handling so that it can be used by third parties.

    Once the tool is ready, it must be tested and validated by a third party. In this case, it would be NIST/NIJ (which is where my own tools were validated). NIST has a mobile forensics testing and validation process by which Apple would need to provide a copy of the tool (which would have to work on all of their test devices) for NIST to verify. NIST checks to ensure that all of the data on the test devices is recovered. Any time the software is updated, it should go back through the validation process. Once NIST tests and validates the device, it would be clear for the FBI to use on the device. Here is an example of what my tools validation from NIJ looks like: https://www.ncjrs.gov/pdffiles... [ncjrs.gov]

    During trial, the court will want to see what kind of scientific peer review the tool has had; if it is not validated by NIST or some other third party, or has no acceptance in the scientific community,
    • But this assumes that the data is wanted for prosecution and it has to be admissible. Seems reasonable that they might just download the contact list and start investigating those people. The data from the phone will never actually be used in court. So in that case, they don't need an instrument, just the facts, so to speak. Ed
      • by sims 2 ( 994794 )

        Well I don't think they are going to prosecute the phone owners as they are rather dead.

        Otherwise they are dealing with terrorists and terrorists don't have rights the govt just sends them to gitmo and keeps them there indefinitely without charges.

        Funny laws that we have nowadays.

      • by guruevi ( 827432 )

        If you want to maintain the constitution (I know, it's far fetched), all evidence must be processed as described above. If the FBI gets a contact list from the phone and decides to prosecute an individual, all the defense has to do is "well, how did you get that phone number" and if the evidence isn't good/correct or the FBI tells them that it just magically knew who to talk to, it's highly likely that the case gets thrown out right then and there.

  • by smooth wombat ( 796938 ) on Monday February 22, 2016 @12:46PM (#51559801) Journal
    Something which I had been questioning from the day I heard the phone was not the terrorist's but owned by a country government in California, couldn't something such as AirWatch be used to unlock the phone?

    My answer came over the weekend when I read this article [cbsnews.com] which stated the county paid for but never installed such software.

    Having been responsible for setting up iPhones for a state agency, one of the steps was installing AirWatch which we did have to use on a few occasions when people locked themselves out.

    Not installing such software is either incompetence or laziness on the part of the IT folks who handed out these phones.
  • Smoke and Mirrors? (Score:3, Insightful)

    by JustNiz ( 692889 ) on Monday February 22, 2016 @01:24PM (#51560225)

    I'm seriously wondering if this whole thing could really just be a giant PR/marketing exercise by Apple, when in fact they are already complying with the NSA?

    http://www.theguardian.com/wor... [theguardian.com]

  • While I support Apple's stance on this issue, it really doesn't apply in the California case. Authorities already had access to the phone from the start. Local authorities inadvertently reset the password and do not know what it is. The FBI is requesting help to reset the password that the authorities had put on the phone, not the shooters. As such, why would Apple not help?

    All of that said, the FBI is also wrong. While it is one thing to request help with this particular phone. Trying to force Apple to

    • by mark-t ( 151149 )

      The biggest reason why Apple would not help, other than the possibility that there is no help they are capable of offering (which is conceivable), is that by doing so, they would be confirming beyond any shadow of doubt that it is even actually possible.

      The realization that something is physically possible is a *HUGE* incentive for some people to try and figure out how it is done, and if Apple can do it, then so can other people... people with much more nefarious intentions than even an untrustworthy gov

  • It's a *way to install* a backdoor.

    In meatspace, Apple does not have the keys to the building, but they have a key to the tool shed where you can build a new handle and lockset that has a maser key, and a screwdriver which would alloy you to replace the current door handle with the compromised on. Apple will not let the FBI into the toolshed, nor help them create the faulty (master-keyed) lockset.

"I have not the slightest confidence in 'spiritual manifestations.'" -- Robert G. Ingersoll

Working...