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 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 is even more personal item and even more networked item than any laptop maybe already is, but at least in my opinion. So 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 keys as well, your private, public keys, et cetera. 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.

Um, 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 on the server. 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... Mac OS X versus iPhone OS, desktop versus phone. 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 on the phone. 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 access-- keychain access identifier for which, you know, the current application that connects to it. I'll get into more details later to make that really clear. And last of all, the SecKeychain API doesn't exist on the phone. We have the SecItem 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 just 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 was more in line with those usages.

And therefore on iPhone OS, we're going to introduce a streamlined API called the SecItem API, and that's going to replace -- or that will be a replacement for the SecKeychain API on the phone. Now the SecItem 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 SecKeychain 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 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. 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 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 cheeky, because four API functions, yes, and what, 30 constants to 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 and 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 key chain. 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 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 between Eccles 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 we're going to simplify our case a little bit. We're going to use Internet passwords, but in our case, the HTTP passwords that we have have a lot of attributes that all of the items that we're going to store are going to share. So the function only gets account, server, and password data, and we'll just go from there. So the first step, I'll get into detail on the next slide, but we're creating this dictionary. We're setting it up with all the common attributes that we're going to store in this one item. Then we're going to add, like, the various values that were passed in, like the account, server, and the password. They all go into that same dictionary, and then we pass that, of course, to secitemat, which then goes ahead and adds the item to the keychain. And that's all there is to it. Now, to go into detail about what actually goes into that dictionary that I didn't talk about yet, here's the function we used to prepare that initial dictionary. Note that we'll actually use this function throughout the various examples. First thing to do is create the dictionary. Then we want to specify what class. We're gonna do Internet passwords here. And then we're gonna specify port protocol and authentication type. A little lame, but port, of course, has to be specified as a CFNumber. A little bit extra work, but, you know, we hope that the benefit outweighs that.

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 the password passed in is the one field that we actually want to update. We don't want to just say, like, you know, 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 sec item update. As 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 the two values passed in. And now one thing that changes is we'll have to tell it what do we want back from this item.

There's various things in a password that you could get back. The thing here that we're interested in is the password. So we're going to specify, I'd like you to return me the data and set that to true. And then we run sec item copy matching, which will then return us the password. Now, if you actually had specified a subset of attributes and more items would be found, then maybe you'd also like to see the remainder of those attributes. You can also specify ksec return attributes and set that to true in the dictionary, and that would then give you back a dictionary that would not only contain the attributes but also the password as a separate attribute in that dictionary. That's different from this case here, where the password is actually returned to you as the CFData that you created as you passed that in. 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 gonna 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 keychain. 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 keychain 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 gonna 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 alike. They're not actually just dictionaries of values. They're actually a slightly larger object, 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.

So we pass in that dictionary to sec item add, and you will see that now in add, we're actually using that second argument in which it will return us the persistent ref that we just asked for. As I already said, it's like an opaque blob, but it comes back to you as a CFData. You can store it. That should make it easy to store it wherever you want to, you know, in a preference or whatever.

There's no security violation here. That data doesn't need to be kept secure. Of course, you know, if someone modifies it, you'll obviously be using a different identity, but that's a different problem. There's nothing, there's no sensitive data in it. Thank you. Okay, so we have the persistent ref. Now 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 a 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 gonna 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 gonna ask the user to pick which particular item I want. And now I'm gonna tell it, "Okay, not just one." I'm gonna be explicit. I'm gonna 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, you know, 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.

So we don't have a secret by which anyone can prove that they have ownership of this keychain. It makes it a little harder. But what we've done for now is we've said, like, okay, we're going to put just every application in their own access group. The access group gets set to your application identifier that gets signed in when you sign your applications, and that will be the basis for which we will either put items in with that access group or which will let you access items that have that same access group. Now, there is a possibility for multiple applications to actually share items by which they could specify additional keys. It's not currently documented, but it's important that you know that in the current setup, it is possible if you say you have a profile and you actually write applications for one particular domain that you could generate application A and B and set them up in such a way that both of them actually end up seeing the same portion of the keychain. They have the same access group, they can access the same items, and they can share as such.

So with that, let's go over to certificate management and keys. A simple one to start with, a SEC certificate doesn't really need a lot to say about it. It represents an X.509 certificate on the phone. One specific issue with that is that it is only RSA keys that we currently handle, nothing else. Now, there's not much use out there, but if you see that as a great problem, again, file bugs, let us know. Sec certificates just, like on the desktop, can be stored in the keychain. They use the class, this sec class certificate class to separate them out from the passwords. And when you look for them, you actually end up specifying Ksec return ref versus, you know, return me the attributes or the data to get a reference back, a sec certificate ref back that you can then use with the various sec certificate APIs. There's not many of them, but the one that I wanted to share with you is a sec certificate copy subject summary. If you end up in a situation that you say have multiple identities and you want to show the user something to identify it with, you could go from the identity to the certificate to a presentable string that will try to find a short human-readable string for the purpose of that particular certificate. It will try to be smart. I can't guarantee that it's not going to, you know, show you two certificates that end up having the same label. It would be unfortunate, but there probably is another way around that. So that's all for SecCertificate. Let's have a look at set key.

So key represents both asymmetric, both public and private keys. Again, only RSA. It can also, you know, represent symmetric keys, but we don't currently use that. You shouldn't be too surprised if those show up in the future, but they're not currently there. Those would be used mostly as reference keys where the key material would not be stored in your process space, but actually would be handled by a security D on the phone.

So keys can also be stored in the 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 set 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. Set 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, laptop gets 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, you know, client-side authentication, then you would have to get that public key off the device and possibly use 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, and with that, you can obviously do raw signing, verifying, encrypting, decrypting operations. So that's SecKey.

SecIdentity is, of course, the logical follow-up to that. SecIdentity 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. SecIdentity 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 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 the 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 encrypted with a password, and sent 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.

And what's the most-- the biggest reason why you want SICK identities on the phone to begin with? Probably client-side authentication. Now, how do you do that on the phone? Because some of you may have already found we're a secure transport. Well, you do that using CF network, and I wanted to quickly highlight again, like, how you actually manage to get those things set up. First thing to get set up is when you authenticate to a server, you may have to actually specify not only your identity, but the intermediates that lead up, you know, to the route that the server may actually trust.

So you create an array that contains, on the first location, the sec identity ref, and on, you know, further locations in the array, you may have additional sec certificate refs. Then you go ahead and set up that array that represents your identity plus its intermediates as the CFStreamSSL certificates property, in yet another dictionary that then gets set on the CF read stream with the KCF stream property SSL settings. So it's two dictionaries wrapped in each other. One other one that I wanted to point out here is that if you end up working with identities and you have custom identities imported, you may actually not have them signed by a certificate authority. So you may have just created them yourself, and you may need to do custom SecTrust evaluations.

So what I've also done in this example, as you see, is there's a property, the CFStreamSSLValidateCertificate chain. I've set that to false, but this is not, you know, a great suggestion here. I'm telling CF Network to don't do that work, but I'm not telling it that it's not important. I'm just telling it I'm gonna take care of that later.

So if I do that, then I get to SecTrust. I just connected with the server, and the connection is actually open now because we negotiated, and we didn't decide to verify the server just yet, so now it's up to me to verify that. So I can get a SecTrust back from the CF read stream by asking for the SSL peer trust property. The SSL peer trust property is actually new on the phone. you will not have seen that on the desktop yet. What it will give you back is a SecTrustRef, while on the desktop, the only way to get that out is actually as an array of certificates. We thought it would be more useful to give you just a SecTrustRef on which you could immediately evaluate your custom trust. So for a custom trust evaluation, there's probably additional things you would like to set on the SecTrust before you evaluate it. Now, the most important one, if you use some self-assigned identity that you don't want to make trusted for the whole phone, but just for your particular application, is the SecTrustSetAnchorCertificates function, which allows you to specify an array of anchors that you expect the evaluation to arrive at. So when the server authenticates to you, it will go complete the chain and try to build up, and if somewhere in this chain it contains one of these certificates that you set up as the anchors, that will be trusted. That brings up a little distinction. Here we're saying anchors. Anchors means, like, somewhere in the chain anchored to this certificate that is slightly different from root certificates, where a root certificate is a self-signed certificate that, you know, generally ships with the system. Here it is purely for the purpose of saying, like, I want trust to be anchored by these certificates.

The other thing you might set is, you know, if something was signed in the past or something like that, to set the verify date on there. And then after you've set up your SecTrust, obviously, you're going to evaluate it. As you evaluate it, only then will the trust chain be built. So don't access anything about the SecTrust until you have done evaluation. Only then will it be in a state where you will be able to get data out of it. The most important item is, of course, it's going to return you the trust result. The only trust result you will probably ever see is the unspecified trust result. It's a little crazy naming, but it's something that we inherited and didn't feel strongly to change on the desktop. What that means is basically the evaluation went fine. It's all good. The only alternative you'll probably see is a recoverable trust failure, which just means, like, well, it didn't work out at all, but... So what you're looking for is unspecified.

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 SecTrust 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, you know, 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. Or setkey, of course, had, like, all kinds of raw signing and verify operations, but we already discussed those, so I will leave that one out now. So common crypto, common use algorithms. Here are some of the, well, here are all the symmetric encryption, decryption algorithms that we support. We support them still only in ECB and CBC mode, and for the block ciphers, there's optional P7 padding so that, you know, it fills up the blocks properly, and it will be able to tell you how long the original encrypted message was.

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, you know, convert your OpenSSL calls into the appropriate digesting calls in common crypto. So 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 SHA-1 and HMAC SHA-1 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 devrandom and get some bytes out. Well, this one actually doesn't do it any different. It opens devrandom 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 dev random 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 sec random, 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. SecRandomCopyBytes 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.

So out of the box, it has the same certificates as 10.5.3 has. So there should be no surprises in what CAs that we support. And you can use keychain access and look at the system anchors to quickly find out whether your favorite CA is actually in there or not. But then beyond that, end users, of course, may want to add some. There are a bunch of certificate authorities out there that just don't make it into apples for whatever political reasons exist, and they may want to just go ahead and add them. And for that, there's three different ways to do that. First, there's configuration profiles, and that was really born out of the necessity of a larger enterprise provisioning a whole bunch of phones in one go, and they'd like to, you know, be able to just do one configuration and drop it on there and not go for anything else. So that automates for them the whole configuration, and that includes adding certificates to the trust store. A way a user like me at home can do it for their own mail server is I can either go into an email attachment of a message that I sent to myself. Of course, you know, that's not super trusted. We don't have signed email on there. But I authenticated to my mail server. I can be happy with that at times. Of course, that would be a little bit of a snake biting its tail if that was for my mail server. But if you have an email attachment that happens to be a CR or a CRT or a DER file, it will show up as a special type of attachment, just like, say, a Word document would, and as you click on it, it will take you through the configuration necessary to allow you to accept it.

Then there's also downloading them via Safari. Same issues apply. You have to be careful where you get it from. But if you get it, say, from a trusted source where their certificate was trusted by a CA before, and you can go to their secured HTTPS site and get their certificate and by that slowly extend your chain so that you also trust other servers that they maintain that they had only signed with the new certificate authority that you just added. If you get into the issues of supporting certain certificates as anchors for a particular purpose, don't immediately add them to the root certificates database.

The root certificates database will be trusted for every application. So if you just had some badly protected certain key that signs a bunch of certificates for a particular application, you don't necessarily want anyone walking off with one of those setting up a mail server that would show up as like, yeah, I'm pretty trusted. the only thing it would require is for someone to just blast your DNS to bypass it. I won't go into detail, but, you know, there's many issues that exist with that. So if you can keep it as low level as your evaluation of that trust, you can use the API on SICK Trust to set the anchors specific for this particular evaluation and be done with that. So, That's all I had. In summary, use the keychain. It allows you to store passwords and other secrets. Effectively, it creates a keychain for every application. So what you see is all that you added, unless you end up sharing with another application. Try not to include algorithms or functionality we already provide. I know it's hard because there's always this limited set of APIs that are out there. They're limited for a reason, right?

We're trying to keep it small. We have to exclude things just to make it all fit and have people not complain about having to be able to store less music on their phone than they already can store on it. Common Crypto is there for the algorithms that we assume you're already using, so if you have additional requests, if they get into Common Crypto, they will eventually show up. Use CF Network for TLS SSL. Let us know what the problems are with that. You know, I wrote the test program. I know I can do it, but, you know, I'm sure that some of you have great ideas for other applications, and we really need you to write that bug to make it explicit what things are missing for you to make that work for you.

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 sec item. 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's additional information they can learn from those. However, this afternoon, there will be a 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.