How iOS Security Really Works

Thank you.

You're all amazing for coming to a security talk at 4:00 p.m. I know it's been a long day, but thank you so much for coming. My name is Ivan Krstic, I head Security Engineering and Architecture at Apple, which is the group that built security from the ground up into every product we ship to users.

Today the focus is iOS. And I am so proud to tell you about the role security has played as a key design philosophy for that platform.

Before we dive in, we need to set some context.

Why is security so important to Apple, and why do we believe it is so critical to our users? The answer is because our mobile devices are an unprecedented record of our lives.

Never before in history have there been objects that know so much about us. About how we spend money.

About the emails we send, and the photos we take.

About our messages. From our quickest hellos to our most intimate conversations.

When you think of it that way, you realize that protecting the security of all that information is so much more than just about technology.

For us it's a mission, and it's a mission that is nothing short of protecting the digital personal sovereignty of our users.

And when you think about it that way, you also realize that the very definition of attackers has changed.

Attackers today might be criminals looking to hold your data for ransom.

They might be unscrupulous business competitors looking to gain an edge. They might be internet service providers looking to indelibly mark your online activity for tracking and advertising without your consent.

It could be nation states, like in the 2014 hack of Sony Pictures.

And sometimes curiosity can get the better of even those close to us.

And then, of course, we must never underestimate the power of the advanced feline threat.

Thank you.

So when you think about all of these attackers, what do they want? We find that the motives tend to group in one of three groups. There is personal stalking and surveillance, which is trying to access your photos and your messages, gin access to your camera and your microphone, then there is corporate espionage, which is gaining access to your business emails and documents and your intellectual property, and then finally, there is direct financial benefit, stealing money directly from your online banking session or injecting ads and committing click fraud while you browse the web. And to do these things, attackers have created adware, spyware, ransom ware, remote access Trojans, and a variety of other malware. How do we know this? Because we've seen it on other platforms.

But not on iOS.

Nearly a decade after it came into the world, there hasn't been a single piece of iOS malware that has affected our users at scale.

This is because nearly 10 years ago, Apple realized what role mobile devices would come to play in the lives of our users.

We realized that existing security technologies would be woefully inadequate, and could not step up to the challenge, and so we decided to build the best security technologies that we could imagine to protect our customers, at a scale that is staggering. We are protecting users that use over a billion active iOS devices all over the globe.

And every single one of our security features protects a real user from real threats. But we are not in this alone. There are really three key pillars to iOS security. There is platform security which are the technologies that we build into our software and hardware.

There is users who upgrade their software to the latest and most secure versions, and then there's developers like you, who use our security technologies to build secure apps. We're going to talk about all three pillars today.

We'll start with platform security.

When you think about how security used to work, especially in enterprise settings, it was a long and complex list of thing that users have to do to try and be secure. Loading secure configuration into their devices, complex batch management schemes, complex password policies.

It was difficult, it was heavy handed, and it set up users to fail. It was so hard to be secure.

But because Apple owns all the hardware and software, we were in a position to address this in a unique and innovative way.

When you look at iOS security, we've built security directly into the silicon. We have made the devices that are secure out of the box by default.

We've made it really easy for our users to update and run the latest and most secure version. We have made it really easy to log into the devices securely with Touch ID.

We have a curated App Store, and we've made security easy to use. IOS platform security consists of a great deal of features, and today I only have time to highlight five.

We'll start with Secure Boot.

One of the most important ways of being able to trust a device is to trust the software that runs on it.

And the way we do this is by building trust into the silicon.

The Apple design system chip inside every iOS device holds Apple's public keys in an area of memory called Boot ROM, which is read only. It's written in the factory and cannot be changed after that.

And when your iOS device starts, we take that public key and the Boot ROM will validate the next step in the boot chain, which is the low-level boot loader. And only that validation passes will we move on to the next step in the chain, and we'll repeat this until iOS has fully booted, which gives us confidence that every piece of software that was used in boot was signed with Apple's Private Key.

When you think about secure boot, it's really interesting that we don't rely on any third parties to deliver secure boot trust. We don't rely on certificate authorities that are outside of our control.

The keys used or secure boot are generated management provision by Apple. The code that does the verification that I just showed you is written by Apple, and only Apple is in possession of the private keys required to sign all the software. But there is another interesting element of this, which is that when an iOS device goes to update the version of the software, it has to contact our installation authorization server, and ask for permission to update to a given version. And it does this by taking cryptographic measurements of the update, sending them to the server, and asking whether it's okay to update.

We do this because the server is now in a position to deny an iOS device the ability to move to an older, less secure version of iOS. And so when you put these two things together, you get a strong and trustworthy mechanism for relying on the software that runs every iOS device.

It's not possible to copy an old version of iOS from one device to another. It's not possible to tamper with the integrity of the software of this process. Now, let's talk about protecting user's data at rest.

If you're really serious about doing this, you don't want to take the cryptographic keys that protect user data and make them available to the application processor or the normal processor in the device. That is because the attack surface there is simply too large.

If you're serious about protecting user data at rest, you build dedicated silicon that holds those cryptographic keys.

We've done it.

We call it the secure enclave.

Now, when you think about passcodes, normally they're very short, four to six digits.

And if somehow an attacker were able to take the encrypted data off a phone, or off an iOS device, and attempt every single possible passcode, it wouldn't take them very long.

So what we do instead is we take the user's passcode, and we derive a key from it that is untangled with the hardware key that is only available to our secure enclave.

Which means it's not possible to guess passcodes offline. Passcode guesses must happen on the device, and the device is free to limit the number of attempts.

In fact, this is exactly how your iOS devices work.

After a few incorrect passcode attempts, we start imposing a time delay.

But after 10 incorrect passcode attempts, the secure enclave will simply not unlock that device again.

This has nothing to do with the erase data feature, where if it's on, the data will actually be erased after 10 incorrect passcode attempts. Even if you have this feature off, once 10 incorrect passcode attempts are made, the secure enclave will not unlock that device again regardless of how much time you give it.

So we built the system using industry standard algorithms.

We've subjected it to rigorous internal security audits, and third-party code review, and then we've taken it a step further. We have taken our core cryptographic libraries that underpin data protection, and we've posted them on the web for everyone to download and inspect.

Let's talk about sandboxing.

Sandboxing is a method for isolating data between apps.

This is because even with the best of intentions, developers sometimes make mistakes, and sandboxing is a way of mitigating some of the potential harm from those mistakes.