Good morning everybody. Thanks for coming. I'm glad to see such a full room at 9:00 AM. That's actually encouraging. This is session 208. Andrew, Michael and I are going to be talking to you today about securing iOS applications. And to be a little bit more specific, we're going to talk about how to protect the user's data at rest on the device as well as when you transmit it across the network.

The application we have for you today to demonstrate is called Oversharing. It's basically a simple device-to-device photo sharing app. We didn't try to make any UI demos. This is really focusing on the crypto below it. What basically happens is these devices will be able to discover each other using Bonjour, tell each other, "Hey, I'm interested to see your pictures." Then any time the other device that takes a picture, it sends it back to the requesting device and says, "Here's another picture for you." The source code is not available on the website, but we will take it with us to the lab.

We'll skim the surface and talk about the high-level calls that you'll be making. There are, of course, a lot of details that come into place to make the application work. If you're really curious to see how that works, please meet us at the Security Lab. That will actually be right after our session.

Another thing to ask is we will be using Wi-Fi. If anyone brought a Wi-Fi base station with them and it's sitting right in the front row, you could turn it off. That would make it probably better for us than the demo gods. We'll hope that it all pulls through.

So why would you secure this app? I mean, you could say, like, well, it's just a fun app, right? I'm just using it to share some pictures. But after you send your app into the world and a customer downloads it, of course, there may be other things that they do with it. They may potentially take an embarrassing picture.

If they take an embarrassing picture, well, you know, they're in for a bad surprise if it turns out that their picture can be, you know, caught in midair or basically pulled from their device. So you have to kind of assume that a user may use your application for any purpose necessary and that they may actually care for you to protect their data. And as we'll see today, the steps necessary are really not that hard, or at least that is what we'll try to convince you of today.

So, the threats that happen are a little scary and abstract. So, when we talk about brute force and man in the middle, you've all also seen those in the news and you may have thought like, well, you know, yeah, it's bad, but I don't really know what it means. That's another thing that we want to try to show you a little bit more up close, that these attacks are fairly practical.

And besides that, These threads are real because, well, you've potentially lost track of your device and had to call it and then retrieved it from the couch and suddenly it's like, oh, okay, there it is. But you had that moment of, oops, where is it? Well, another thing that may happen is you may know someone that lost it at a conference. Could happen. So it can be out of your control for a while and someone can go ahead and do everything that we'll show to you today.

So lastly, your device is networked and it will really get all of its data and send all of its data over the network. There is really no other way to go and there is no such thing as a secure network. There really isn't. You can have a secure transmission across a network, but networks themselves cannot be trusted.

So how can our APIs help you? We're going to do this in three large sections. I will start covering the securing of network connections, which is pretty much the securing of transmissions across a network. Then we'll talk about protecting data. This is protecting of data on the device, so pictures that you've taken and stored locally.

As well as protecting secrets. And secrets generally are credentials that you may actually use to retrieve additional data from the network and you may cache it on the device. But those secrets actually protect the data that the device pulled off of the network and they're equally as important to protect.

So let's talk about our application for a moment. Our application is going to work in the following way. One device is going to send an HTTP GET request to another device that it sees on the network using Bonjure. And then as soon as that other device has acknowledged this other device, it can send back via a post. It will actually start publishing pictures back to the device that requested the pictures, and it can do so continuously. So it will basically push its pictures out to the person that asked about them.

So how do we do this using the high-level API? First, the GET request. You start with the URL. The URL here is already prefabricated. Of course, in our application, we will need to fill in which device that is. So the address that we put in here is fictitious. We are going to basically do a Bonjur lookup and insert that host in there.

Then we are going to create an NSURL request. And to create an NSURL request, which holds all the state around this request, you first need an NSURL. But an NSURL is easily created from the string. And then we have our NSURL request. Now, at this point, you have the request.

And the way that you can manage this thing, there is an NSURL connection, which is kind of a manager for the request object. You hand it to this NSURL connection, and it takes it through the paces. It goes through all the various steps that are required. And as it does, it is specified a delegate, which is your controller.

And your controller can then basically implement the protocol called the NSURL connection delegate. And so that sounds potentially difficult, but really what it does is it implements very simple calls like did receive data. Whenever this request has been run, data comes back to the device. The callback will be called, or the delegate will be invoked on your controller, and it will present you with the data.

Or if something goes wrong, there is of course the failure message as well to let you know like this request didn't go anywhere, and that will of course be the end of it. There are additional methods that we'll get to later, but let's continue with the POST request.

The POST request is very similar. We start again with a URL. We turn it into a mutable URL request, because this time we don't want a GET request. We actually want to POST data to the other side. So after we've created the request, we need to make a couple modifications.

One of them being, this is a POST. We're actually pushing data out to the other side, and we're setting the image data up as the HTTP body to present it to the other side. So the picture that we've taken, we convert it into data, set it as the body, and then send it. So with that, I'd like to invite my colleagues Andrew and Michael on stage so that we can demo to you how this app basically works.

I will be using the iPad that is tethered, so I will be tethered to my booth here a little bit and Michael will go out. So let's see if we can, yep, there's my application. We're going to connect to each other. I'm going to go around and look and there's Michael's iPad, so I connect to him. He's going to do the same. He may have already connected to me. I'm set. And so what we can do now is ask him to take a picture.

I told them not to take pictures of me. And there's a picture. Alright, so we can do this the other way around as well. Let's take a picture of the audience because I was playing.

That was the picture you sent? Yep. Oh, that was a different one. Okay. One last one? Sure.

So, with that, I want to turn it over quickly to Andrew to let us know how we are doing. So, I'm fascinated about what these two gentlemen are sharing, and I really want to get my hands on those images. So, I've been in the coffee shop, these two gentlemen are sharing images, and I've got my own setup on the same wireless network. Or I could be another colleague wanting to snoop on this, or just driven to evil intent by the prospect of doing a live demo with packet capture.

So, I walk over to my device, and we've got some images that I've just pulled straight off the wire. This was done very easily, I didn't actually write any custom code myself, simply a script which recombines TCP flows, dumps out to a file, strip off the HTTP header, run it through the file command. Is it a... JPEG? Yes.

Rename it, let Finder do the rest. Very simple. It doesn't require a huge amount of technology to perform an attack such as this. So I am seeing that maybe there's nothing interesting being sent over at the moment, but if I wait a bit, maybe I'll get some of those juicy images.

So that was our first demo. This was for most of you probably obvious, we're sending data across the network, but at least now you saw that it's actually not that hard to intercept. So what happened? We connected to each other, we didn't use a secured connection, and the network is kind of like this room. Anyone who has a conversation, anyone else can overhear it.

And in this case, Andrew was right there to pick them up. You noticed some of the pictures were like a little choppy, but of course that has everything to do with how you make the packet capture reliable. And I'm pretty sure that there's people in this room that can do better than we.

So how are we going to improve this? Well on the client side, this is really simple. I already kind of hinted at it. If we use HTTPS, this high level request will go down and use secure transport to make an SSL connection. So on the client side, it's one letter change.

Great. But let's talk about the server for a moment because as you realize, these applications of course have to also implement the server. So for that, we're going to quickly discuss secure transport. Now to set up secure transport, there's first some setup steps that are necessary. There is a SSL new context that creates the object that holds all the state for an SSL connection.

After that, there are the callbacks that are needed. The callbacks whenever we want to send out some data over the network or if we want to actually get some data from the peer to see whether they send us some data. That is the SSL set IO functions and it will have a couple of callbacks.

I refer to the sample code if you want to see how those callbacks are supposed to work. They have some... detail necessary to them to understand how they work. Of course, you may already know from the desktop how they work, but the application will illustrate that more closely.

Of course, just having these callbacks, you may want to reuse them for multiple connections. So there is also an SSL set connection that allows you to set a context object for this particular connection. So that any time your callbacks are invoked, you will be told this is the exact connection that we're talking about. It's just a void star, but you can basically cast it to whatever you want under the covers to go over. So that you can go find all your state again. And finally, we need to set up the certificates.

We're going to deal with that a little later. After you've set up the connection, it pretty much works like any file would. It's basically an open read/write close cycle. SSL Handshake will go ahead and set up the secure connection after it's done, which may take a couple of steps. You can call SSL read, which will read the unencrypted data from the other side. And SSL write to send data to your peer.

And finally, you can call SSL close again to say, like, okay, finish up the connection. That will only finish up the secure part of the connection. The network connection, of course, continues to be open to send more data across it. So this will only shut down the secure part of the connection.

So, I skipped certificates, and most of you may say, like, well, you know, certificates is difficult, I don't want to deal with this, but it's actually relatively easy. But if you skip certificates, you may find, like, hey, yeah, I can do that. I can use this one cipher suite here. It doesn't require me to set up a certificate. And so, our example here is an example that uses a Diffie-Hellman key exchange, which is secure between two peers.

The two peers will share the same secret at the end of it, and nothing else. Then you get the AES encryption in CBC mode with 256-bit keys. That seems rather hard to brute force. And, of course, all your packets are protected by an HMAC using SHA-1. So, anything that's modified uses yet another key to make sure that you can detect these modifications.

This is of course encrypted, but it's not secure. If we make this connection, say Michael makes the connection to me, as shown here, we know that there is a connection between the two of us, and when we send data across, no one else can really easily see it.

They see a bunch of encrypted data flying across. But why is it not secure? Well, imagine that Andrew switches from a passive attack to a more active attack. Now, whether he does this by faking Michael's endpoint so that I accidentally connect to the wrong IP address, or whether he does this by having an entire environment up, like say this rogue base station of his that we're sitting on, and he manages in such a way that basically he can put himself perfectly in the middle of us, what will happen is Michael will connect to Andrew, and he will be able to connect to Andrew.

He'll do this Diffie-Hellman key exchange. He has a secure connection between him and Andrew. He doesn't know that it's Andrew. Andrew goes ahead and makes a connection to me. I don't know who's in the other end. And if Michael sends a picture, I see the picture. So what has happened now is like Michael and I are none the wiser. We have the connection set up. We know that it's secured, but Andrew is still seeing the pictures. That was not what we set out to do.

Certificate Authentication. We're going to go back to that because it's actually relatively easy and that way we can stay within the realm of HTTPS. You can of course implement your own zero-knowledge protocol over an anonymous Diffie-Hellman connection, but again, let's show you how to do that easier and just stick with TLS. For Certificate Authentication, we're going to use asymmetric cryptography and it's going to use an asymmetric key.

An asymmetric key is different from a normal key. In normal crypto, you use one key, you encrypt a bunch of data, you get ciphertext, you use that same key, you decrypt it again, and there's the plaintext again. With asymmetric cryptography, you have a key pair. There's a related key, two related keys, there's a public key, and there's a private key. The public key you can actually feel free to share, it's actually part of how it works. And there's a private key that you must keep secret.

Now, how do we go through this? This is one of the models in SSL that happens. But it's the easiest one to explain. So, what I can do is I can use my private key to create a signature over a bunch of data. What will happen is I create a checksum and then I do an asymmetric crypto operation which will sign it for me and give me the signature blob.

Now, if I go ahead and pass someone the signature blob, plus the data of course that came across that we signed, as well as my public key, the other party can happily take my public key because my public key is not going to allow them to sign the data, but I can use it to verify that the data that was signed by me with my private key was actually signed by me. Now, this doesn't show you exactly who I am yet. This only shows you how I can prove that I had possession of a key.

So, the who is actually where the certificates come in. If we zoom in on the certificate that we have, if you look at it at a very high level, There is actually our public key in there, which of course we needed to prove to the other side who we were.

But then the who is not in there, the key is kind of an anonymous bag of bytes. So there's also an entity in there, something that talks about whether it is my SSL server, my web server or something. And so this combines basically the who it is plus what key they will be using.

That can of course be modified unless you go ahead and sign this. So let's use the same method that we just used to basically make sure that the signature is formed over the subject in the public key and add the signature to the certificate. It just sits there separately, but anyone who basically takes the public key that belonged with the private key that created that signature on it can verify that the subject and public key combination in the certificate were not modified.

Now of course it would be pointless if we did this to our certificate itself because well then we can only trust it based on this one certificate. So generally speaking there will be someone else's private key that signs your certificate. And so you can form a little tree.

This root certificate that came into view basically has a public key in it and a private key that someone else holds and they went ahead and put the signature on my certificate. Now anyone who trusts this root certificate will also be able to approve it. So that's the first thing that we're going to do. So we're going to authenticate all the certificates that it issued.

Now for that our devices actually trust an awful lot of certificates. So there's about 250 now so that makes it a little awkward. But basically that is the trust pool where we start from and as a result we can trust the leaves that are dangling off of this large tree.

So, Michael and I work at Honest Apes. We already have our configuration profile installed. We actually have our own CA in-house that, you know, bicycles can only make you that much money. So we decided to open up a certificate store here as well so that, you know, saves us some money. But we basically have a CA. So we have our two applications. Our applications both need a certificate to connect to each other. So we're going to take the root certificate and we're going to issue ourselves two certificates and basically add them to the application.

So in SSL, when you normally use it, only the server really authenticates to you. When you use a website, that's okay, because the information is technically public. You only want to know when I go to this particular source, I want to see something that is actually theirs, not someone else's.

Server authentication, if I connect to Michael, he is going to authenticate to me. And thereby, I know this is Michael. But in our situation, that's not enough. Because imagine that Andrew connects to Michael. No problem. Michael will authenticate to Andrew, but if he actually starts sharing pictures, he would actually be happily forwarding pictures to Andrew, which was kind of the point.

We were trying to make sure that Michael and I could share pictures without Andrew seeing it. So the only thing that server authentication does in this scenario for our app is it avoids me connecting to Andrew and getting, for example, a LOLcat sent to me instead of a picture that Michael took.

If we do client authentication, Michael will also authenticate to Andrew. As Andrew tries to authenticate, Michael notices, "Hey, this is not Conrad," and drops the connection. That stops it from happening. For our main scenario, that will still work because as Michael asks me to authenticate, he'll notice, "Oh, that's Conrad.

Good, we can make this connection." And then in the future, he can start sending me pictures because he knows that he talked to me before. And in future connections, I am the server. He'll know that's Conrad that I'm sending to. And I'll know that Michael is actually sending me pictures instead of Andrew sending me wallcats. So now we have mutual authentication. How do we do this? So we're going back to our delegates.

Whenever our delegate is called for receiving data or errors that happen during the connection, there are a couple of authentication challenges thrown our way. The first of which is going to be for this client certificate. So the delegate did receive an authentication challenge and it passes as a challenge.

Now we can inspect that challenge and notice that what it's asking us for is "I want a client certificate". The other side asks us "Hey, please authenticate yourself so I know that I want to send data to you". After this happens, we create a credential and actually just set it. Fairly simple. Now how do we get here? You see us creating this NSURL credential and we're creating it with an identity.

Identity is really very simple. It's just a composite object that really just puts together my private key as well as my certificate. If you put those two together, you know, for logical purposes we have this identity object. And that is what you create the NSURL credential with. Now you could also pass along more certificates, but that's another detail that I don't want to get into right here. That is also not necessary for a basic mutual authentication as you'll see.

Before this delegate is called, there's one performance optimization that is pretty much a, are you going to handle this particular authentication challenge that is called first? So the first thing URL connection will do before it even asks me for a client certificate is ask me, like, do you support that? And so when that is being called, I return yes, and off we go. So let's demo how our application works with SSL enabled. All right, so there's my device again. We're going to connect to each other again. Did you notice that really nothing has changed? I'm connecting to Michael.

Michael probably connected to me. Maybe he can start with the pictures. Oh, not me again. All right, well, great. There's a picture of me. Now I'm going to pass the buck right around and go back to Andrew. One more for the audience because you guys have been so patiently listening. You should be part of the show.

As you saw, we managed to use the app without any other thing. It worked the same way as it did before. That's pretty good for us as users. Let's see what Andrew got. So I've noticed that Michael and Conrad are back on my network and I've been running the same utility I was running earlier, and let's see what we've got.

Lo and behold, I have no more images. Well, I could see them using the application, so what's going on? Maybe my little setup here is broken. But if I go over to my intercepts folder, I can see that, yes, I've got some traffic here, but if I look at it, that's very odd.

That doesn't look like... I'm going to show you how to use a JPEG. In fact, it looks incredibly encrypted. So maybe they're doing something else. At which point, I could go in and, say, do a traffic flow analysis and perhaps use the Wireshark utility, and I can see, ah, they're using TLS.

Out of that, I can get information such as the certificate, because that goes over privately. And I can find out that they're using their company CA, which is Honest Apes. And as it happens, I happen to know somebody who works in the IT department of Honest Apes. He's mostly just a bicycle repairman, but he does it on the side. And as a favor, I said, "Hey, you know, I've got these friends, Michael and Conrad. Could I have some certificates for them?" And lo and behold, I got them.

At the end of it, we do the same thing as in the other one, whereby we specify back to the delegate, like, "Okay, let's create a credential out of the trust that we've evaluated successfully," and pass that back. If we do not trust the other party, we return nothing, and as we come out of this delegate, the higher-level APIs will close the connection and basically flag the error up to your application.

So, in summary, I think I've tried to show you that HTTPS is fairly easy to use from the high-level API use, and it does require some setup work to use these certificates. But it provides a simple experience which, you know, it only adds to oversharing and remaining a fun application.

If you have to dig in and get some more things out, Secure Transport has a host of options that you can use to optimize for your purposes and other methods of authentication. But, of course, you have to watch what you're doing. Again, hit us up at the lab if you want to discuss those options, and we can help you with those.

So, finally, let's see what happened now that we restricted our routes. I do not trust Honest Abe's anymore. Let's see what happens when I go ahead and try to go across the network. Imagine that Andrew is sitting there with Honest Abe's certificate, and he's publishing Michael's name, and I'm just connecting to him.

And as I go ahead to connect, I basically get the error back up at the top level of my client, which is "did fail" and there are some additional information passed to me which says like, "Well, Michael's iPad, we don't trust it. That certificate that you're using, we're not currently trusting anyway." And an unhelpful suggestion of would you like to connect anyway, "Of course I don't. I want to keep this connection secure." So we're going to cancel out and leave it at that. And hopefully we'll find a network where we can share pictures without Andrew getting in the middle.

Thank you. So, now I really am lost. They've completely secured their network connection and I can't get in through that method at all. However, very handily, as Michael walked off stage, he left his iPad here and he forgot it. So, well, what can I do with this? Of course, by default, there's no way I can get at the raw file system on a device. But the files are just there in plain text.

And if there's something such as a forensics tool or jailbreaking or some other utilities, I might be able to get at the raw data on the file. So, let's see what we can do there. So, there might have been some pre-demo setup here, but I've just plugged it in. And let's run this demo tool and see what happens. Oh, we have some images coming across. That looks interesting.

Lo and behold, it looks like the images that were sent earlier. So even though I am now forced to no longer attack them on the network, I can attack the device if I can get physical possession. It sounds like maybe there's some work to be done there, but at the moment I'm still happy.

Protects data in case the user loses physical possession of the device assuming you set a passcode on that device. Which obviously I had, but since our application wasn't using data protection, Andrew was able to get access to all that data. And as Andrew pointed out, there's widely available hacking and various tools that will let you access the file system. So without using data protection, there really isn't much protecting your data.

The way data protection works is, we have a file on the device. That file is encrypted using a randomly generated file key. Then the file key itself is encrypted with a class key, which is also a randomly generated key. That class key is in turn protected by a device key on the hardware and the user's passcode.

Those two are scrambled together using a special algorithm that makes it hard or impossible to offline attack the user's passcode. It basically forces you, when you want to brute force the passcode, you have to brute force it on that particular device. Because the device key is a per device key that can't be extracted out of the hardware. So this makes it that if your password is strong enough, if the user's password is strong enough, their data would be protected, assuming that you guys actually start using data protection.

There's a number of APIs in iOS 5 that support data protection. There's the NSFileManager APIs, and basically there's a key added there called NSFileProtectionKey, and there's various NSFileProtection options to that key, which I'll go over. CoreData has the same key and has the same options. NSData has the same options, but they're called NSDataWritingOptions instead, but it's the same exact functionality.

We even added it to SQLite, so if you're creating a SQLite database directly rather than using CoreData, you can create a data-protected SQLite database. And SecItem, which is the Keychain interface, also has data protection, and historically those are called attribute-accessible, so they're described as accessibility rather than protection, but I'll show you the mapping between the two. They're the same.

These APIs are nice, but for probably 95% of the people in this room, your applications only run in the foreground. So when the user clicks the menu button, the application goes away, your app isn't really doing anything in the background. For those apps, adopting data protection is as easy as adding an entitlement called Data Protection Class.

and setting that to NSFileProtectionComplete as its value. At that point, all of your application's documents and files that it creates will automatically be protected with the highest data protection class available, which is ProtectionComplete. Which basically means that none of your application's data can be accessed unless the device is unlocked at the time. So as soon as the user hits the lock button, about 10 seconds after the lock timeout goes off, so you can set in settings, you can set go to sleep immediately or after one minute.

Once that timeout expires, apps get about 10 seconds time to clean up, write their files. At that point, the keys are thrown away by the kernel and there is no way to decrypt that data unless you re-enter the user's password. So this is what probably almost all of you should go do today.

Let's say you're not in the class of app that just runs in the foreground and you need to use some of our APIs because you have some files you need to access in other cases. Here's an example of what we would use in our application here to write an image to our album.

What we do is we get the data out of the UI image and then just call NSData's write file to path with the data writing file protection complete option. Which makes basically that image protected and only accessible when the user's password is entered and the device is unlocked.

Some things to consider is that data protection is only as good as the user's passcode. If you have A as your password, it's not going to be very good. Even though we limit the speed at which you can brute force it to about 10 tries per second, if your password is a four-digit PIN, that's only 10,000 options. You can go through those in a couple minutes. Users do need to choose a somewhat longer passcode for it to actually make any real benefit.

As we said, you can't access these files when they're locked, and you can't create them when they're locked. Now, what if your application needs to be able to create files while the device is locked? Let's say, in the case of our oversharing app, we want to receive images while my device is in my pocket. So, I connected to Conrad's device, but I put my device in my pocket. Conrad's taking pictures, I still want them to be stored on the device and archived. Well, since it's locked, I can't create files with NSProtectionComplete. For that, we have another class called NSFileProtectionCompleteUnlessOpen.

Under the covers, that actually uses an asymmetric key pair to protect the data. So, what happens is the private key is protected by the password, but the public key is always available. So, the system is always able to create new files. And as long as you keep that file open, the kernel lets you read and write to that file. As soon as you close the file, the key for that file is thrown away, and the only way to get it back is with access to the private key.

And since the private key is protected by the passcode, if the device is locked, you can't reopen the file. Now, because it uses asymmetricKypto, it puts a slightly heavier load on the system. So, as a general policy, it's good practice to upgrade those files to ProtectionComplete the next time your app is able to do so.

I'm going to show you how to do both those things. So here's the write images while locked method again. And this is the version that actually works even when the device is locked. So first we try to write the file with protection complete. And if that fails because the device is locked, we just write it with complete unless open. And that's basically all there is to it.

So, as far as the startup code that we have to do to upgrade things, We start with looping through basically all the files in our album directory. And for each file that isn't already protection complete, so we look at the file attributes. If it's not protection complete already, then we create a dictionary saying, set the protection key to complete and set the attributes on the file. So this is using the file manager APIs to basically modify the protection class of existing files.

So, there's a third class of apps, which what if in addition to receiving pictures while we were asleep, we wanted to actually provide some kind of album service that people could connect to after the fact and download pictures. Well, that means that someone would actually be able to need to be able to read files while the device is locked. Now, this is a class that we'd rather you not use unless you really have to because the downside of this protection class is once the user enters their passcode, all files of protection complete until first user authentication are accessible to the system until you reboot the device.

So, what this means is if you took your phone to like through airport security in some country where you're not really sure what they're going to do with it, if you power it down or restart it before you hand it off to the customs officer, these files are protected.

If your device is just locked, then in theory they could still pull those files off using a forensics tool. There are cases where you need to use this, which is why we provide it. It's still better than not protecting it at all. So, the example case in our case would be we're making a background service that lets you download images.

Here's how we would make a SQLite database that can be read and written even when the device is locked. Let's say your application is something that runs all the time in the background, some kind of system service, then you could create a database using file protection complete until first user authentication.

So with that, I'm going to bring Andrew back on stage to see if he can hack into our app now that we have some data protection enabled. So, yet again, that careless chap Michael has left his device lying around and I've got hold of it. So, let's take a look and see what I can get off it this time. This time it appears to be locked. And there's a, I need to set up the same, there is a long password set on it. So let's see what we can get off it.

So this time we're running the demo tool and we get operation not permitted. And that shows that while this device is locked, I can't get in. And the chances of me getting to the device before that 10 seconds elapses is quite small. However, say for example you are in an airport and there's a charging station that happens to be hanging out of the wall. And you think, okay, I better lock my device before I put it into this charging station. I don't quite trust it. Make sure you wait those 10 seconds for those keys to be thrown away.

And you also might think, well, we use flash storage on here and it's very difficult to properly get rid of keys. You might have heard that's a problem with some issues. But we've actually created a special part of there where the keys can be easily thrown away and we can guarantee they're overwritten. And for brevity, I think I'm going to leave it there. But I'm now fully locked out of that device and my evil plans to steal the embarrassing pictures. So, now we've seen how to use data protection. And you think, well, that's great.

Now I know how to protect all my data. So, if I need to store a password, I'm just going to write it into a file that's data protection complete. And that's where we kind of want to make a little change because we have another API here called the keychain.

And to talk about what belongs in the keychain is, as Conrad alluded to earlier, what belongs in the keychain are secrets. And what we consider secrets versus data is... Secrets is anything that would give you access to additional data. Say, you know, a credential that you need to log into a service or a key that you use to encrypt something. Those things would be stored in the keychain.

The keychain has actually been around since iOS 1 and the keychain has always been our most protected layer in the system. So, keychain has, in addition to data protection, some higher level controls that let you control migratability, it has different access groups, so it's partitioned between applications. And there's some other features of the keychain that make it something we'd rather see use that for credentials than just storing them in a file.

So, example would be, you know, storing username and password because we want to add functionality to our oversharing app to upload pictures to the system. Other than asking the user for their password each time, we store those credentials in the Keychain. How do you do this? Well, you use the Keychain interfaces and the way you protect the data in the Keychain is you set the accessibil- the atter accessible, which basically tells you when you need to be able to access- or you're telling the Keychain when your application needs to be able to access the data. And if you say, "I only need to access the data when unlocked," that's equivalent to data protection complete.

If you say, "I only need to access the data after first unlock," that's equivalent to complete until first user authentication. And then finally, there's always, which is equivalent to no data protection. So the default for Keychain, if you don't set the accessibility attribute, is when unlocked. So it's the highest protection level.

By default, these classes also let Keychain items migrate, which is to say, if you backup your device and you've set a backup password and you restore that backup to a different device, any items marked with any of these accessibility attributes will show up on that new device. Most of the time, that's what you want, if it's a credential or a password.

Sometimes, the credentials or keys or whatnot you're storing in your application might be bound to the device itself, and you would want to get new credentials when the user gets a new device. So if you need that, there are variants of these where you append this device only to the name of the accessibility attribute, and that prevents those items from migrating to a new device. If you backup your device, wipe the device, and restore the backup password, you might want to set up a new device. If you don't have a new device, you might want to set up a new one.

I want to show you an example of how you would use a Keychain in your application. For that, we start with a helper function that we're going to use everywhere called QueryForAccount. This is in the case of our oversharing app. We're going to use a generic password item. Most of the time, you would probably be using an internet password item, which has a bunch more attributes.

For brevity, I'm using a generic password item here as an example. We're setting the class to generic password. We're setting the service to oversharing. We're setting the account to the account name on the service that, in this case, was passed into this function. The passwordForAccount function is the first function your code would call. Let's see if we already have the password in the Keychain. First, we get the query. Then we add one attribute to that query, which is return us the data, please.

Now we say copy matching. Give me something that matches this query. We get back the data for that item. If it exists, if it doesn't exist, The Keychain and the Application Data are important. Learn how to use the Keychain and the Application Data. Understand how to use the Keychain and the Application Data.

Understand how to use the Keychain and the Application Data. Understand how to use the Keychain and the Application Data. Understand how to use the Keychain and the Application Data. The other function we need is, well, if the password wasn't in the Keychain, we need to store it. We need to set password function.

So for that, again, we call the query for account, which is the helper thing. Then we set the data attribute. So we set the value data that actually sets the password on the item. And then we set the accessibility attribute. And we say we only want to access it when unlocked, which happens to be the default, but it doesn't hurt to be explicit. And then we add the item.

And then finally we have the update function, which is very similar to the set. The difference is that this is what you would call to modify an existing item that's already in the Keychain. Let's say we had an item in the Keychain, but the password was wrong because the user changed their password on the server. You prompt the user for their new password, and then we update the Keychain item when we're done. So for that, again, we get the query. Now we create a second dictionary, which are the changes we want to make to the item.

So, we want you to store, you know, credentials, secrets in the Keychain. There's really no excuse anymore not to use the Keychain. There used to be, prior to 4.0, Keychain items didn't migrate if you had a new device. So, that was the reason some developers were like, oh, we don't want to use the Keychain because it's a bad user experience when the user gets a new phone. That's no longer the case.

We want you to protect files with the best possible data protection class available. And again, the first example I showed you, if you're not running in the background, just set the entitlement. You're done. No code. And then finally, encrypt network traffic as appropriate. Here's a list of some of the reference guides, talks about the different APIs we touched on today that are related to security. With that, I'd like to thank you all for coming.