Forgot your password?
typodupeerror
IOS Security IT

Apple Releases IOS Security Guide 91

Posted by samzenpus
from the protect-ya-neck dept.
Trailrunner7 writes in with a story about a iOS security guide released by Apple. "Apple has released a detailed security guide for its iOS operating system, an unprecedented move for a company known for not discussing the technical details of its products, let alone the security architecture. The document lays out the system architecture, data protection capabilities and network security features in iOS, most of which had been known before but hadn't been publicly discussed by Apple. The iOS Security guide (PDF), released within the last week, represents Apple's first real public documentation of the security architecture and feature set in iOS, the operating system that runs on iPhones, iPads and iPod Touch devices. Security researchers have been doing their best to reverse engineer the operating system for several years and much of what's in the new Apple guide has been discussed in presentations and talks by researchers. 'Apple doesn't really talk about their security mechanisms in detail. When they introduced ASLR, they didn't tell anybody. They didn't ever explain how codesigning worked,' security researcher Charlie Miller said."
This discussion has been archived. No new comments can be posted.

Apple Releases IOS Security Guide

Comments Filter:
  • I can dream... (Score:1, Insightful)

    by cuncator (906265)
    Hopefully it says "security through obscurity does not work" in big block letters on the first page.
    • Re: (Score:1, Troll)

      Hopefully it says "security through obscurity does not work" in big block letters on the first page.

      It's what this security guide doesn't say that is important to Apple. I'm betting they left out a few tidbits of information. Not a lot, but just enough to make us think the guide is complete.

    • Re:I can dream... (Score:5, Insightful)

      by Jeremi (14640) on Friday June 01, 2012 @03:09AM (#40177273) Homepage

      Hopefully it says "security through obscurity does not work" in big block letters on the first page.

      Of course, in the cases where it did work, you'd never hear about it.

  • by w0mprat (1317953) on Thursday May 31, 2012 @10:16PM (#40175733)
    Would like to see a comparison to Androids security model. Anyone care to analyse?
    • by Anonymous Coward

      I bet they both pale in comparison to the 35 Page pdf documenting the security features of QNX from RIM.

    • by Anonymous Coward on Thursday May 31, 2012 @11:44PM (#40176187)

      Android's what?

      Oh, good one. You had me going there for a minute.

    • Re: (Score:3, Interesting)

      by captainspudly (551559)
      Charlie Miller and Jon Oberheide will be speaking at http://summercon.org/ [summercon.org] in NY June 8 on Android. I hope to hear some good comparisons.
    • by IamTheRealMike (537420) <mike@plan99.net> on Friday June 01, 2012 @07:32AM (#40178299) Homepage

      Well, "security" is a huge topic and the mechanisms are constantly evolving. But there are some differences that are worth analyzing.

      Both operating systems run apps in a sandbox, unlike desktop operating systems like Linux or Windows (OS X is starting to move in the mobile-ish direction). There are some tasks that the OS simply forbids apps to do entirely. In this regard they are similar, and in the absence of local root exploits it's much harder to write viruses that target such a system.

      The main differences are as follows: the iOS sandbox is somewhat weaker than the Android sandbox. It restricts fewer things and in the past (not sure if it was fixed these days), key first-party apps such as the web browser were not sandboxed at all, which is how several generations of jailbreak worked. Android was designed from the ground up with the mentality that there should ideally not be an "us vs them" divide - Android treats all apps more or less the same, security-wise, meaning that the browser is just a regular app that runs in a permission-controlled sandbox like any other. This open design is one reason why the permissions UI on Android is more complex than for iOS - apps can do more things and the OS has to communicate that to you.

      With a weaker sandbox and permissions system, Apple relies much more heavily on manual review and the ability to control what software you can run. Android, by default, will not install software from outside the Google Play market (which does have various forms of review by the way), but if you tick a box and acknowledge a warning box it will let you do so. This is another reason the sandbox is stronger - Android phones can and do run code controlled by nobody but the author. iOS requires Apple signatures in all cases. The impact of the weaker sandbox is also mitigated by the fact that iOS users upgrade at a faster rate than Android users do (though it's still nothing compared to systems like ChromeOS), so when sandbox escapes are found they can be fixed faster. Android is more vulnerable, which is why there's more of a rigorous approach to privilege minimization.

      With the virus angle largely taken care of, "malware" on these platforms is being redefined to mean "software that does something the users probably won't like" rather than "software that does that, and also takes over your machine / hides from you / both". For instance if you install an off-market app on Android and the OS tells you "Services that cost you money: send SMS messages" when you install it, and then you install it and it sends premium SMS in the background, that's typically being classified as malware by various AV companies .... which is kind of fair, but the remedy is just to uninstall the app. These apps can't resist uninstallation or hide from you as desktop viruses can. And beyond obviously bad stuff like running up a phone bill, they're also starting to classify apps that have poor privacy practices or which are too aggressive with their advertising as "malware" which is rather questionable.

      With regards to other features, like drive encryption, as of the latest releases I believe both operating systems are largely comparable. The biggest remaining difference of interest (at least to me) is the approach to secure boot. Apple uses a form of online authorization to personalize OS reimaging to the device, this is to avoid downgrade attacks where users jailbreak the device by reflashing to an older, vulnerable version of the OS. Android secure boot is largely up to the OEMs and their approaches differ .... some like the Google Nexus devices allow you to reflash to any OS image you like, including ones you compiled yourself. No authorization from anyone is required, however, the phone will do a data wipe before performing the reflash to stop people who stole your phone from stealing your data too. Other phones will only boot firmwares signed by the manufacturer and use eFuses to stop downgrades rather than a server.

      • --in the absence of local root exploits it's much harder to write viruses that target such a system.--

        Now the only phones I can think of that do not have this are BB's. What a shame.

      • --Android, by default, will not install software from outside the Google Play market ---

        My Android was set up to sideload right out of the box although most people only use Amazon for this.

      • by bushing (20804)

        This is well-written, but mostly incorrect, based on some bad assumptions about sandboxing and encryption.

        The main differences are as follows: the iOS sandbox is somewhat weaker than the Android sandbox. It restricts fewer things and in the past (not sure if it was fixed these days), key first-party apps such as the web browser were not sandboxed at all, which is how several generations of jailbreak worked.

        No, the iOS sandbox is stronger, in that it supports more fine-grained control over access to individual syscalls (based on the BSD-heritage Mandatory Access Control framework), as well as the API-level and filesystem permission-level isolation that Android relies upon. Jailbreaks didn't rely on a lack of sandboxing, for the most part -- they exploited kernel bugs in e.g. the graphics driver. It took

    • Android has a security model? Oh, I forgot about ICS's possible one. Doesn't any smartphone but a BB have decent security out of the box?

  • The important link (Score:5, Informative)

    by OzPeter (195038) on Thursday May 31, 2012 @10:25PM (#40175781)

    The most important link missing from TFS is iOS_Security_May12.pdf [apple.com]

  • by Anonymous Coward

    . . .and in turn, Cisco will release the iOS Security Guide.

    • by OzPeter (195038)

      . . .and in turn, Cisco will release the iOS Security Guide.

      And just to confuse things even more, GE had an IOS product (an automation controller of which I am sure there are still plenty in service) and currently has an iOS product of their own.
       
        Sievers Super iOS [geinstruments.com]

      • Even more confusing, the firmware used by the Wii is referred as IOS as well.

        • by mlts (1038732) *

          Add to that IBM, where on POWER7 hardware, the AIX-based OS used for the VIO servers is called IOS as well.

          oem_setup_env is your friend, although IBM does not support this way of adminning a VIO server.

  • Bad Grammar (Score:5, Informative)

    by sethmeisterg (603174) on Thursday May 31, 2012 @10:34PM (#40175825)
    Not "there best" -- "their best". Editors??
  • Everyone has been thinking Apple will launch a TV (as if!), but with the release of this guide, my suspicions are confirmed - the next major Apple product is iKeelYou, an enterprise/home defense bot.

    The security manual is here to prep us with the understanding that the core of iOS has the strength, security and doggone sticktoitiveness even the most stringent critics would demand from a completely autonomous bot capable of decapitating anyone at any time.

    Thanks Apple for helping me and my boss sleep a littl

  • by Anonymous Coward on Thursday May 31, 2012 @11:45PM (#40176191)

    Yes, Apple is so sneaky and secretive we never would have learned about the iOS security model without this unprecedented revelation. I feel so fortunate to live in the age of apple security enlightenment. If only there was some way [google.com] to divine such special knowledge before this document was disclosed.

    Security Starting Point for iOS [apple.com]
    iOS Security Overivew [apple.com]
    iOS Secure Coding Guide [apple.com]
    iOS Security Reference [apple.com]

    The list goes on ... [apple.com]

    • by dgatwood (11270)

      Thanks for pointing that out. I was going to do so if nobody else did.

      Of course, the big difference between the developer docs and this new doc is the audience; this doc specifically targets IT people, whereas the developer documentation targets... yup, you guessed it. Although the developer docs try to cover enough general information so that the IT folks won't be completely in the dark, details such as the encryption algorithms used under the hood are, to a large extent, out-of-scope for developer docs

  • by antifoidulus (807088) on Friday June 01, 2012 @12:11AM (#40176337) Homepage Journal
    unprecedented move for a company known for not discussing the technical details of its products, let alone the security architecture.

    Um...no...not by a long shot. While obviously nowhere NEAR as open as Android, iOS is based on Darwin, which is open source(though I am sure they have modified parts of it but not released them, and of course 99.9% of userland is closed). This is the base from where most of the "security architecture" of iOS is derived, and briefing though the guide, most of what it talks about is based on these open source OS level features(and the parts that arent are basically references to APIs that Apple has documented for years). Yeah, author needs to get a clue
  • by grouchomarxist (127479) on Friday June 01, 2012 @12:51AM (#40176571)

    It is curious that TFA is from the "Kaspersky Lab Security News Service" and yet Chrome is warning me that "This page has insecure content."

  • It's just a hunch, but my guess is that Apple is planning or at least contemplating to move to a complete whitelist approach to security for both the iOS (where it is already implemented almost completely) and OS X. This would drastically improve security if Apple were able to write programs without exploitable bugs. Since like every other company Apple is not able to write such programs and in any case uses the wrong architecture, tools and programming languages for it, in reality it does not affect securi

  • Each step of the boot-up process contains components that are cryptographically signed by Apple to ensure integrity, and proceeds only after verifying the chain of trust. This includes the bootloaders, kernel, kernel extensions, and baseband firmware.

    Haven't they heard of redsn01? (although A5 devices are more secure)

  • That's what I want to know. If my iPhone is off or locked, other than being pistolwhipped into unlocking it, how safe is my data from those widgets the cops are starting to use for random device copying and snooping?

    Assuming of course, auto-wipe is turned on and I used a complex passphrase for locking?

    • None of that matters, just look at the jailbreakers. The cops can use the same techniques. Put the device into DFU mode and do anything you want with it.
      • by swb (14022)

        According to the NSA document on securing an iPhone, mail and some other app data is encrypted and cannot be read easily, but 'normal' filesystem data uses an encryption key given out to any process (I read this after posting my original message). Apprently apps can also request their data be encrypted using the same difficult-to-decrypt methods used as mail, but many don't (I know GoodReader can do this, and I enable it).

        • So then you just patch the mail app when it's loaded to piggy back your own code. This is a feature built into Objective C. You could probably also bypass the lock screen in a similar fashion.
  • Does anyone find it funny that the link in the submitted story about security causes Chrome to display a warning banner reading "This page has insecure content" and blocking that content by default unless you foolishly choose to allow it to dowload the insecure content???

"The chain which can be yanked is not the eternal chain." -- G. Fitch

Working...