Yes but six almost sounds like sex so we had to censor it.
Anyway this guys, right here, has sold me every iPhone I own. The incredible lengths to which Apple go on security on iOS is incredibly valuable to me.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Full Video of Apple Engineer's Black Hat Security Talk Now Available
- Thread starter MacRumors
- Start date
- Sort by reaction score
Anyway this guys, right here, has sold me every iPhone I own. The incredible lengths to which Apple go on security on iOS is incredibly valuable to me.
Err. No. This is why Apple launched their Bug Bounty Program. To find and fix bugs – people gaining root access in iOS can get a reward up to $200.000 from Apple, or a $500.000 reward from some other entity.
Security measures are believed to be good and safe until someone breaks them. As we know, anything can happen. Even at Apple. In my view it is only a matter of time before someone gets in and goes for that reward... why else would Apple launch this program?
The main issue I have with this program is that it was launched far too late, is focused on iOS only, and is only open to a dozen or so known researchers. One word; limited.
Now take a look at the security of OS X (and macOS) and Apple's OSS policy. First. They only share source code of stuff that they think matters. Like nothing else can be broken. Good from them to push out the XNU source code of 10.11.6 sooner than what Apple normally does, but on Mac hardware you are far far far from safe... and there is no bug bounty for OS X (and macOS).
So. Now it is time for Dr. P.R. Alpha to go after some of that money... and I already made $750.000 from bug bounty programs
Plus I think security flaws are far more likely when an O/S runs on a multitude of CPUs and devices in different hardware configs. iOS runs on apple devices period. Most android phones run different modems and wifi chips so there must me more loopholes. I saw someone mention RIP jailbreak but I don't think that's the case. It was man made, someone will find a flaw. No such thing as 100% secure IMHO
True, there will always be flaws. But using these flaws to jailbreak will, on average, take increasingly longer. At some point it will take so much effort, it's no longer worth it.
Now if only I were intelligent enough to do this kind of work! That's a pretty good incentive to help Apple debug and find vulnerabilities in it's software.
1) agreed, 2) they seem to consider it a much bigger target, and 3) actually, they've said that if you show up at the door with a sufficiently good case, you 'll get an instant invite to the party.
I don't expect the decision on whether or not to share source is based on what they think can be broken or what matters, but rather on what is or is not proprietary. All the GUI frameworks are their self-written code, and quite valuable to them (I totally get this - I use OS X because it's a UNIX workstation with a seriously good GUI, something that Linux has been trying and failing to deliver for many years). If they released all of OS X / macOS as open source, other companies would be slapping it on cheap PC hardware and competing against them on price. I'd love to have more (qualified) eyes on that code, but I can understand their position.
[doublepost=1471455354][/doublepost]It appears I'm in a minority position here - I watched the first part of it (got interrupted), and I don't feel lost, I feel giddy - love seeing other developers doing cool things, everything they said made delicious sense.
Right now, Android as a platform lacks a lot of the security features that are present in iOS.
The notion of effaceable storage (a specific place of NAND flash that can be guaranteed to be erased because wear leveling is disabled) is not present at the OS layer in Android. Different phone manufacturers have had problem with storing keys on flash and not successfully erasing them.
Android has full-disk encryption which is turned on by default on some devices. This will lock the device until the passcode is entered. However it does not have the individual file-level encryption support that the Data Protection API provides, and does not have the different protection classes that is discussed in the video.
Android does have a Keystore API which provides out-of-process crypto. This prevents against an attack where a process is compromised: the process can't get access to the keys themselves (to, say, copy them off the device). Additionally, this API may use secure hardware if that hardware is available on the device and the manufacturer tied it in.
Since so much of this is depends on the vendor implementing things, applications on Android often need to build or buy their own solutions for securing data. Fortunately, Android inherits a lot of encryption capability from the Java ecosystem, so there are a lot of options. But my feeling is it's a lot easier to protect data on iOS than on Android right now.
The notion of effaceable storage (a specific place of NAND flash that can be guaranteed to be erased because wear leveling is disabled) is not present at the OS layer in Android. Different phone manufacturers have had problem with storing keys on flash and not successfully erasing them.
Android has full-disk encryption which is turned on by default on some devices. This will lock the device until the passcode is entered. However it does not have the individual file-level encryption support that the Data Protection API provides, and does not have the different protection classes that is discussed in the video.
Android does have a Keystore API which provides out-of-process crypto. This prevents against an attack where a process is compromised: the process can't get access to the keys themselves (to, say, copy them off the device). Additionally, this API may use secure hardware if that hardware is available on the device and the manufacturer tied it in.
Since so much of this is depends on the vendor implementing things, applications on Android often need to build or buy their own solutions for securing data. Fortunately, Android inherits a lot of encryption capability from the Java ecosystem, so there are a lot of options. But my feeling is it's a lot easier to protect data on iOS than on Android right now.
3.) maybe I wasn't clear enough. I mean. Bug bounties should not be invite only. Even if they would accept good POC's from anyone.
Also. I was only talking about the kernel. Not the GUI frameworks. The problem is that the XNU kernel itself isn't 100% open source.
You're not alone. I've been doing information security for a good 20 years. Apple clearly has unique challenges to solve.
I can't speak to the situation here, but having participated in some other bug bounties, both open and invite-only, running a bounty program of this magnitude isn't as easy as opening it to the world and waiting for the flood. Processes have to be tweaked. Teams have to be trained. All sorts of things happen in the background that the public forgets about. You send an email with "hey, I found this and here's the PoC" but lots of things happen in the company. Someone has to review it and establish risk. They have to send it to team(s) to review and work on fixes as appropriate. Then this all happens for hundreds of reports. Many of them absolute garbage. "lawlz, I found your SPF record is set incorrectly, pay me nao." You laugh, but I've seen those. It takes time to process all of these reports. My guess is that Apple limited it to known researchers because they won't have a ton of false positives weighing down the security team while they tweak the processes for handling reports.
I understood most of what he was saying, and its damned impressive. Coming up with something like this requires otherworldly experience and imagination; but its only possible if you control everything. I'm sure Google has similarly amazing people but with so many vendors of Android devices they cannot control the hardware and software sufficiently to build a system as strong as this. By controlling every aspect of the hardware and software design (and even cloud hardware) you can put something together with this level of sophistication. I doubt that an external agent can get very far unless then can bypass the physical one-way hash function (which is my favorite new cryptographic tool).