Is it on now? Yes, it is. Well, you missed the first joke of the morning, but I will continue in English instead of Dutch. I was just going to say that I hope one day I'll be able to just have, like, a room to myself where I can do it in Dutch. It would be so fantastic. Anyway, let's get through this. Actually, I have a fairly short session, which will leave more time for Q&A, which is actually good because I'm sure you have a lot of questions, and I actually also want to hear some feedback from you guys.

So, the session, Managing Secure Data on the iPhone. The phone, you know, is an even more personal item and even more networked item than, you know, any laptop maybe already is, but at least in my opinion. So, you know, what are you going to do about all that secure data that people carry around and care a lot about? So, secure data, in general, you have various kinds. Basic ones, like passwords, then, of course, you know, keys as well, your private, public keys, et cetera.

Or just, you know, plain data that you actually bulk encrypted or had signed. So, what do you do with that on the phone? Well, good news is we also have the keychain on the phone. So, you know, your passwords, your certificates, your identities, all of that can go right in there.

But the remainder of your data, you have to choose what to do. Now, either you can store it locally on the device and use bulk encryption to keep it secure, but you may also say, like, well, you know, I'm so well networked now, maybe I'm just going to leave the data. And in that case, of course, you want to have a good strategy to have secure communication with your back-end server that your phone is talking with.

So, this morning, what are we going to go through? Most of the functionality I'm going to talk about is in security framework and some of it in the libraries that are related to it. I'm going to have to make a distinction a little bit between Mac OS X and the iPhone OS or the OS X iPhone, as it's called now.

These names change so fast. I'm going to refer to them as desktop and phone. I think we'll all be happier with a short term that says what it says. So, first, those two, then we can get into the details of what exactly is there, how do you deal with the keychain on the phone, how do you deal with certificates on the phone, TLS, SSL, how does that work, low-level crypto, to finish it all off. And root certificates, I'm actually not going to get into APIs as much because there are non-public ones.

But I'm going to bring it up because it is, of course, of interest and I'm going to show you at least what an end user can do or a company that wants to provision a bunch of phones. So, first off... A lot of things are similar. Obviously, we're not going to just start completely from scratch. One of the key pieces in that is, of course, having common crypto, which contains all of our algorithms. A subtle difference already apparent there is that on the phone, we actually have some crypto hardware.

And for that, we have acceleration for your SHA-1 and your AES needs. Now, subtlety about that, too, is that one of the reasons to have acceleration there is not just so that you can do it faster on a slow platform. It's also, you know, power-wise, if you have optimized hardware for it, that will actually take less power.

And that is, of course, very useful. Secondary, all the APIs that you know from the desktop, if you have familiarity with the desktop, exist. So, you know, if you look for the header files, you will find them. But there are some differences. And one of those differences is that CDSA is not there on the phone. So whenever the APIs actually use explicit CDSA-isms, we have to come up with a different API to get around that. So that brings us to the differences.

And I've kind of already given away the first differences. CDSA existed on the desktop so that you could kind of hook into a really broad crypto API at the lower level and extend the system in whatever way you wanted. We don't have that on the phone. Of course, it has also grown over the various years into lots of directions trying to serve every need found on a desktop OS, which is presumably bigger than it is on a phone system. And we've actually come up with an API that we pinpointed and tried to gear towards the applications that we expect. And, you know, not only just for time limit, because obviously we couldn't have reconstructed all of it in the time given.

One other big difference is on OS X, you can store stuff in the keychain with one application and another application can come by and say, like, that's the item that I'm looking for. I would like to use that. And then there's the user who can help make the decision whether or not application B can use application A's stored password there and, you know, make the user happy that he doesn't have to key it in again.

Now, on the phone, we don't do that much interaction. You may have noticed that you don't enter a password to unlock your keychain. We sign in an actual -- is the keychain access identifier for which the current application that connects to it. I'll get into more details later to make that really clear. And last of all, the Sec Keychain API doesn't exist on the phone. We have the Sec Item API, and with that, I'd like to get to the next session and talk to you about the keychain.

So the keychain APIs on Mac OS X are pretty flexible and allow you to specify all kinds of things to also make it possible to plug into various other CDSA plug-ins, et cetera. But we looked at what developers ended up doing, and, you know, most of you come up with, like, a simple wrapper over it and say, like, "Okay, this is really what I want." You know, "It's nice that you have this whole API. I don't care. I want something simple. This is how I want to do my work." So we looked at that, and we tried to come up with an API that was more in line with those usages.

And therefore, on iPhone OS, we're going to introduce a streamlined API called the Sec Item API, and that's going to replace-- or that will be your replacement for the Sec Keychain API on the phone. Now, the Sec Item API is different in that it uses CF types. It uses them both for values and for collections. And as a result, we no longer have, like, a Sec Keychain Item ref that you'd first have to get back to query it because, well, we're just going to pass you back the attributes as a dictionary, and you can dig in there as much as you want.

Of course, we have to keep it similar, too. We're not going to, you know, make changes that make no sense at all. So if you have passwords, there's generic-- support for generic and Internet passwords. Generic passwords are really simple passwords. You know, this is the account, this is the server, and this is the password, and that's all I really have to say about that.

Internet passwords are slightly more intricate in that they let you specify the various attributes of an Internet connection, say, you know, what port am I connecting to or what protocol am I using, allow you to specify a little more details, and then you can just go back and look at your data. The schemas of both desktop and phone are the same, so there should be no surprises in that sense. It also stores the certificate keys and the identities. Not much more to say about that. We'll get into the details later.

And it exposes four API functions to do all its work. That's, of course, a little bit, you know, cheeky because, like, four API functions, yes, and, what, 30 constants you pass all those parameters in, so you cannot really measure it by that. But first function, of course, is secitemcopymatching.

You specify what you're looking for in a keychain, and it goes in, digs it out for you, and tells you whether it found something. Then for adding stuff, there's secitemadd and secitemupdate. Those are fairly similar, but they, of course, have slightly different semantics. secitemadd will, of course, not let you add an item that already existed on the keychain, and secitemupdate won't let you update an item that doesn't exist yet.

Those semantics may not be useful to all of you, but I'm sure that there are some of you that will be happy that we have those. And, of course, if you want to get rid of the item again, there's the secitemdelete. One feature that you will not have seen that we thought was really useful is persistent item references.

And persistent item references let you basically find an item and then get back a reference for it that will just be an opaque piece of data that you can just hang onto, and by which you can find that item again and query it for whatever attributes you want from it.

That's especially useful if you have items that are, you know, harder to query for or that you really specifically meant this item and not anything else. And then finally, we have to talk a little bit about the differences between ACLs and access groups that I already brought up. So let's jump in and look at a simple example.

For a sec item add, we're going to start putting all these keychain items on there and

So that was SecItemAdd and the creation of that initial attribute dictionary. What does SecItemUpdate look like? I've highlighted the lines that actually are different between SecItemAdd and update so that hopefully you won't have to read it all again and get a feel for what's different here.

So update actually takes the same three arguments except this time, you know, the password passed in is the one field that we actually want to update. We don't want to just say like, you know, So, the current item has the wrong password. We already figured that out. We're going to update it. So, we prepare the dictionary again with the common attributes for item. Then we add the account and the server to find the item.

Now we create another dictionary because update, of course, has to not only be able to update the password, it also needs to be able to update other attributes, if you like. So, in that secondary dictionary, we stuff in the password that we've now updated and we pass that to SecItemUpdate. It has two values, of course. One is the query. Go find me this item and update here are the new attributes I'd like to set on this item.

So that's update. Now that we have the item on the keychain, how do we find it back? Here's copy matching. Copy matching just gets account and server. We start again with that same standard attribute dictionary we add to two values passed in. And now one thing that changes is like we'll have to tell it what do we want back from this item.

So after that, Sec Item Delete is very simple. Sec Item Delete, again, creates the same dictionary and just says, okay, delete it, that's it.

In the beginning, I mentioned the persistent item refs, and I wanted to show a quick example to see how that would work. Of course, that's not a different function call, but I'm going to show you, like, what attributes actually come in play to use that. So for persistent refs, let's say you have an identity and you're about to store it into the key chain.

Identity is kind of hard to find if you -- hard to find which identity you're actually looking for. You don't necessarily want to parse apart a whole certificate just to find some good attributes in which you can find it in the key chain again. So let's add it and let's ask for a persistent ref back. So here we have a function, persistent ref for identity. We pass in the identity. And now we're going to specify the dictionary for the add call.

We're going to say, like, I would like a persistent reference back. So we set the KSEC return persistent ref to true. And what I'm passing in here is actually not a password item. It's actually a reference to an item. Identities, certificates, keys, those are all in here. So we're going to add it. So let's add it. Conrad Sauerwald Conrad Sauerwald: So let's add it.

And let's ask for a persistent ref back. So here we have a function, persistent ref for identity. We pass in the identity. they're not actually just dictionaries of values, they're actually slightly larger objects, so hence you end up using those as a reference to those items, and we specify that as KsecValueRef, and KsecValueRef will be set to Identity.

Okay. So we have the persistent ref. Then we come back. How do we find that item again? All right. There's the CFDataRef. That's the persistent ref that we have. And as you see, it's fairly similar. This time we ask, hey, give us a ref back instead of specifying it as the value. And we ask for the value as a persistent ref. So we're passing in the persistent ref here is what it means.

Again, same call, sec item copy matching. And what comes back now is actually suddenly not a persistent ref, but what comes back is actually sec identity ref. So that's why you see the casting around. The second argument is a CF type ref. So you'll have to work around that.

All right, so that's how persistent refs work. Another case that you may run into, say you have multiple passwords in there and they actually share a couple of attributes that are the same and a couple are different and you happen to actually want to find all items first to let the user, for example, pick which one they wanted.

All right, so normally it returns you one item and you can be guaranteed that if you don't specify any property. However, if you want multiple items, all the APIs that I talked about can also return arrays of items. That means that if you used to get back a data ref, you'll get back an array of data refs. If you used to get back a dictionary ref, you get it back an array of dictionaries.

For the example here, we're going to say, like, okay, show me, like, all the generic passwords that I have. Ksec class set to generic passwords. Give me the attributes. I don't yet want the value. I'm just going to ask the user to pick which particular item I want.

And now I'm going to tell it, okay, not just one. I'm going to be explicit. I'm going to say, like, hey, give me all items. And I do that with the Ksec match limit property. And that's how you get multiple items out of the keychain. So that was the quick look at SecItem.

Now let's talk a little bit higher level about what it means, this difference between ACLs and access groups. So OS X has a user that can actually make decisions and gets various dialogues in which they can make decisions about whether they want app A to use app B's passwords.

And they can also be queried for their passwords to indicate that they have ownership of that keychain before that can happen. So in that way, there's a very nice way in which you can kind of elevate privileges and redistribute them amongst applications. On the phone, the user doesn't have that password. The user is not the one that can type it in and can do something with that.

So we have the key for them is embedded in the hardware. Someone asked yesterday, is it related to my SIM? No, it's in the hardware. It's in the physical device. It's meant to keep the keychain secure when it travels outside of device, which it will eventually do when you make a backup with iTunes, for example.

Secure Data on iPhone OS and how to carry out basic cryptographic operations, coordinate the secure storage of sensitive passwords and manage X.509 digital certificates with respective trust policies.

Conrad Sauerwald So keys can also be stored in a key chain. They get stored with a different key, the Ksec class key, a little bit of a weird name for that, but it would be more annoying to call it Ksec class key, class key. Also, you get it returned as a ref, and when you have a sec key, then you can actually do the raw asymmetric key operations on it, sign, verify, or encrypt, decrypt, depending on what type of key it is. And you can specify optional padding on it. Currently, there is only PQCS1 padding. Again, if you want OAP or anything like that, file bugs, tell our higher-ups that you need it.

Sec key generate pair would actually be a really nice one to have more fleshed out because we do allow you to generate a key pair on the phone, which is, of course, the most secure way to go. That way, you know, it has never sat on someone's computer or something like that.

So you can actually do that. And then, of course, you can also do that with a lot of other things. So, again, if you have a lot of other things that you need to do, you can do that with a lot of other things. So you can actually do that with a lot of other things.

If it's a mobile phone or a laptop, and you want to make your laptop get stolen in any way, it actually will only be on the phone, but it is not entirely useful to you yet because if you wanted to use it for, say, client-side authentication, then you would have to get that public key off the device and possibly as a CSR to prove that you have ownership of it, and that is currently not a public API. Of course, you could figure out your own schemes around it. It will generate you a key pair. You can obviously do raw signing, verifying, encrypting, decrypting operations. So that's SecKey.

Sec Identity is, of course, the logical follow-up to that. Sec Identity really just represents both a combination of a certificate and its associated private key. The certificate itself obviously contains the public key that goes with the private key and has some additional data signed in by certificate authority.

Sec Identity also gets stored in the keychain. Interesting to note is that they get stored in the keychain as two various, two items, as a Sec Certificate and a key. But you can just use the Ksec class identity to say, like, I want an identity, and it will basically line them up such that the certificates that go with the keys, if it finds pairs of them, that will represent an identity and those will then be returned to you when you ask for that particular class. They also get returned to you as a ref. And, you know, the most obvious thing you do with the Sec Identity is actually ask it, give me the private key or give me the, or give me access to the certificate.

So as I mentioned, there's no way for you to get a generated key on a device off the device with a CSR yet. And although the possibility exists to import a P12 key pair using, you know, the high-up user-level APIs, that won't be accessible to you. So that's why we made the P12 import API public.

With that, you can transport a key and the certificate, encrypt it with a password, and send that blob to the phone and have your application import it. Now, if your application adds it to the keychain, obviously it will own it and it will be able to use it for future purposes. If someone imports an identity to the phone using, you know, email, Safari, then it will actually only be accessible by the applications that Apple ships.

Now that you have a trusted search chain, you either can just go ahead and continue with your SSL connection. You know that you trust the server, and you can start communicating secure data over that channel without worrying that some other party is involved there. But maybe you have a trust chain and you actually want to validate some information. Now, if you want to do a raw verify of a signature somewhere on there, you're going to have to get a SEC key to do that operation.

So a SEC trust ref, after it's evaluated, has the chain, and by that, it can actually get the public key from the leaf as well as possible parameters that may exist in the remainder of the chain to build you an appropriate key with which you can do, you know, encryption or signing.

If after all of this you have a different way in which you'd like to establish whether you trust this particular other host, you can, of course, access the certificate chain as it was built up for you. It gives you access using account and accessing all the items at various indexes.

So that is SecTrust, and by that, I've actually also, on the side, discussed the secure transport issue. On the desktop, there's secure transport, which you could use if you wanted to be, you know, down to the metal or CF network if you like that better. On the phone, we only have CF network. It's the same secure transport, so there's full TLS SSL v3 support. And I've shown you with the examples how we expect you to be able to do custom server certificate trust as well as client-side authentication.

So now we're all the way down to the low-level crypto APIs. Those were similar in terms of common crypto is the same. Common crypto allows you-- for people that are new to this-- allows you to do various kinds of symmetric crypto, and it also has algorithms to do secure hashing and HMACing. We've also added an API called Sec Random to produce you random numbers that may be useful to you if you end up wanting to generate a symmetric key of sorts that you can then store on the keychain to keep it safe for you.

For digesting, we have like a whole suite of SHA digesting. If you were using OpenSSL before and you actually want to make it easier on yourself, you can define the common digest for OpenSSL, do a pound to find of that, before you include the common crypto header, and it will actually include a couple of quick macros that will just convert your OpenSSL calls into the appropriate digesting calls in common crypto. And last of all, there is HMAC. Of course, pretty much similar to digest algorithms, we support the HMAC variant of that.

As I mentioned, some of these are accelerated. So the same goes for this here. AES shall one and HMAC shall one will, as a result, be accelerated if you go across a certain threshold. It's hardware. You have to trap into the kernel. You know, there is a cost to that. So it has some built-in thresholds, but you don't have to think about that. We'll pick an optimal number and do it for you.

So, SecRandom, it's a very simple API. It's really not something that you may need a lot of help with. Normally speaking, you just open DefRandom and get some bytes out. Well, this one actually doesn't do it any different. It opens DefRandom for right now, but in the future, if we have better random number sources, we may, you know, find different ways to do it, and you will be able to access those through SecRandom.

The advantage here of using SecRandom is that it gives us the ability of just opening DefRandom once. You don't have to write the extra lines of code to open it, write a couple of bytes, make sure that it was properly open so you don't just get a bunch of zeros.

But if, you know, all the frameworks end up using SecRandom, then there only really needs to be one file descriptor open to get these random numbers. So that's why there is a function for it. Example usage shows how simple it is. Sec random copy bytes does what you expect. It allows you to specify a type of random numbers and, of course, a length and a buffer to put them in to return them to you.

So that was really all I had for the API that exists on the phone and I'm sure we'll have a lot of feedback from you about it. I did want to talk about root certificates for a moment. Root certificates, of course, play a role on the phone. They are not currently modifiable by user APIs, but I'll show you how a user can currently manipulate them.

And that kind of concludes it. As I said, like, let us know what you need to get your applications out and running. And, well, we'll look forward to seeing some brilliant applications from you guys. So for more information, the documentation was updated so that it also makes references to the various pieces that apply on the phone.

And there is a piece of sample code out there that will specify to you how to deal with SecItem. If you have any questions that you don't want to ask here, you can always contact Craig Keithley. And the related sessions, unfortunately, are already over. They were earlier this week. I'm mentioning them now in case someone watches this on a DVD in a future time, if such a thing comes to pass.

And then they may be able to go back and look at those sessions again and see if there is additional information they can learn from those. However, this afternoon there will be an iPhone OS security lab, which I will also be staffing. So me and a couple of colleagues will be around to help you a little more hands-on than we may need to be able to do here because we will obviously be asked to leave this room quickly for the next session to happen.