Apple Releases IOS Security Guide 91
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."
I can dream... (Score:1, Insightful)
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)
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.
Re: (Score:2)
Comparisson to Android? (Score:5, Interesting)
Re: (Score:1)
I bet they both pale in comparison to the 35 Page pdf documenting the security features of QNX from RIM.
Re:Comparisson to Android? (Score:5, Funny)
Android's what?
Oh, good one. You had me going there for a minute.
Re: (Score:1)
Re: (Score:2)
This is true damned if you do go BB. Damned if you use Android.
Re: (Score:3, Interesting)
Re:Comparisson to Android? (Score:5, Informative)
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.
Re: (Score:2)
--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.
Re: (Score:2)
--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.
Re: (Score:2)
It's probably less secure in the mobile market than any other smartphone. Yeah I get that. What I meant to say was by default sideloading is enabled on certain Android phones, which probably doesn't really matter much as most apps these days want rights to the moon.
If Google wasn't so crazy about Java, it might make some difference. It's just one more way in.
Re: (Score:2)
Well Windows 7 64bit is currently the safest version of that OS unless maybe the phones because no one uses them. It seems with Android all of the cool programs just have to have root access for some reason. It used to be that all windows programs required that just to install and many still do. So Microsoft is becoming more Unix like and Linux is becoming more Windows like probably because of the increased user base that you have mentioned.
Re: (Score:2)
Communist like is a good term for another topic. I was just asking why so many programs need root access at all especially CAD programs? Aren't computers fast enough now that they can stick with the API's and even phones. If it doesn't get you a virus or something like that, it just causes stuff to crash tinkering with the video at the hardware level. Maybe it's all because of ATI drivers, who knows but a program (at least not so many) doesn't need root access. I think that is NOT the fault of either OS and
Re: (Score:2)
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
Re: (Score:2)
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)
The most important link missing from TFS is iOS_Security_May12.pdf [apple.com]
Re:The important link (Score:5, Informative)
Some other links I just stole from a comment in TFA from an anonymous poster
NSA recommendations for Apple products [nsa.gov] (also has recommendations for Linux, Windows and Solaris)
iOS Hardening Configuration Guide [dsd.gov.au] from the Australian Department of Defense
Re: (Score:3)
TFA also forgets an equally important links to prior security material released by Apple [apple.com], which discusses the technical details and architecture contrary to what TFA suggests.
Apple Releases IOS Security Guide (Score:1)
. . .and in turn, Cisco will release the iOS Security Guide.
Re: (Score:2)
. . .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]
Re: (Score:1)
Even more confusing, the firmware used by the Wii is referred as IOS as well.
Re: (Score:2)
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)
New Apple product next week is obvious (Score:2)
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
P.S. (Score:2)
WIth iKeelYou, the "Secure Boot Chain" is an ACTUAL chain.
Ouch!
Re: (Score:1)
That must be why all these large organizations, from government agencies to paranoid corporations, are supporting iOS devices instead of or in addition to the more secure blackberry devices they already have.
Re: (Score:2)
Not conspiracy, just stupidity.
Don't you think that state-level governments are just as capable of making incompetent decisions based on marketing bullshit as upper-level managers?
Remember IBM's problems [gigaom.com] with BYOD? Yeah, none of those are issues with RIM's platforms. BlackBerry Balance keeps personal and business use separate. You can't drop corporate data into the personal side, for example. The user gets to use the device how they see fit, without compromise, and the business gets all the benefits of
Unprecedented Disclosure? (Score:3, Informative)
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]
Re: (Score:2)
To the tune of "Let it snow":
When the docs are all old and dusty,
or the metal case is rusty,
don't blog or call rent-a-thug,
file a bug [apple.com], file a bug [apple.com], file a bug [apple.com].
When the coder throws an exception,
or your cell gets poor reception,
or crashes when you touch the rug,
file a bug [apple.com], file a bug [apple.com], file a bug [apple.com].
When they finally ship GM,
you might like for your app to still run,
'cause a million users' screams
can take away all of your fun.
So when you're tired of all the whining,
and for robustness, pining,
quit being
Re: (Score:2)
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
Re: (Score:2)
Well they just give you administrative rights. Since both IOS and Android are pretty much smaller unix/linux/gnu systems, it shouldn't be too tough to figure out. The developer tools will help you out here.
Sigh, stupidity in the FIRST sentence (Score:5, Informative)
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
Re: (Score:3)
99.9% of userland is closed
When I hear "userland", I like to imagine a safari (lowercase S) theme park where we get to shoot them. ;)
Re: (Score:2)
Re: (Score:2)
It was, until the neon tube failed.
Insecure content (Score:3)
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."
My guess (Score:2)
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
Haven't they heard of redsn0w (Score:1)
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)
So how secure is iOS from roadside police copying? (Score:2)
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?
Re: (Score:2)
Re: (Score:2)
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).
Re: (Score:2)
"This page has insecure content" (Score:2)