Welcome to iPhone Security Best Practices. My name is Dallas De Atley. I'm an Engineer with Core OS. And today we're going to talk about integrating the iPhone and the iPod Touch into the corporate environments. We're going to review some of the basic challenges that IT departments face with mobile devices in general. And we want to expose you to the best practices for integrating the iPhone into your organization.

In doing so, we want to talk about the iPhone system integrity and how we work at protecting not only the user's data but also the services that the user might access with their iPhone. We're also going to talk about some of the security enhancements we've introduced in iPhone OS 3.0.

So what you're going to learn today? We're going to talk about the built-in security features to the iPhone and how we use them and how you can take advantage of them as well. We're going to talk about what it means to maintain the system integrity of the iPhone.

And we're going to talk about the tools and methods and you can use for enforcing your organization's policies about how the users can protect their data and access your services. And with that I'd like to introduce Shawn Geddis, who's going to talk to you about the challenges of using mobile devices in an IT environment.

Thanks, Dallas.

OK, welcome.

Let's talk a little bit about the challenges, maybe you're already facing with mobile devices and how this is going to fit well with getting the iPhone and iPod Touches in there as well. So, first of all, Dallas mentioned we're going to talk about system integrity. And we always like to be sure everyone is on the same page. So when talking about system integrity, we're really talking about kind of protecting the whole envelope, right. All aspects of this is, the unauthorized access itself, the disclosure, modification, that kind of stuff, right. So we want to maintain that.

When you think of integrity, you want to be sure that it stays the same unless you specifically modify things. So when we're going to be looking at system integrity, today we want to look specifically at these four aspects, right. We're going to start out with physical integrity. We're going to be looking at application integrity, going to data integrity, and then finishing up with user. OK, so that's kind of the quadrant we're going to be walking through here.

Now, all of you know, when it comes to security, the biggest thing that you deal with on a daily basis is risk management, right. Security is a constant battle. There's no perfect silver bullet. There's no perfect time and space where you can say, I can relax, I'm secure, right. It's a constant daily battle. And the biggest concern that we all have, when you think about that quadrant, is the things we don't know we don't know, right.

We're always trying to close that in. So the key about risk management here is the fact that we need to identify what those risks are. We need to prioritize that and then figure out how we're going to deal with that, in your own environment. So today, we're not telling you exactly you better do this, this, and this. We're helping you understand how you need to apply this in your environment, OK.

So when it comes to mobile devices in your environment, one of the biggest issues with any kind of mobile device is concern for loss or theft, right. What happens when I no longer physically have control of that device in my hands? Anything can happen at that point, right.

The access of data, whether it's data maybe across the wire, whether it's data physically stored somewhere, it's access to confidential, maybe sensitive information. And then finally, your running application is on there. As we all know, we are at a developers' conference. We're constantly trying to improve our own applications, right. You're developing and enhancing your apps. We keep identifying issues. We fix that. You go on. So you're always worried about application integrity itself.

You're worried about maybe the weaknesses on that side. So those are the risks you take. What are the steps you take to kind of mitigate those problems? Well, some of you in this room might fit that first one, that is-- or your organization might fit that way, and that is we just deny the device, right. You may have had all kinds of PDAs or Smartphones over the many years. Lots of organizations start out with we're just not going to allow it, right, kind of a draconian, you cannot have this.

The other folks you might say, here's the device and then you kind of go and you hope that they know what they're doing, right. Those are two extremes. And today what we really want to talk about is helping you understand how you need to apply these potential policies and controls to help the iPhone fit into your specific environment.

So we're about the policies on iPhone. So the enforcement, we want to ensure that this helps meet your requirements in your agencies. But, first of all, you need to know what those policies are. There are a lot of folks whether they're developers or even in the IT, they want to kind of railroad a new device in their organization. They're not familiar with the IT policies. First and foremost, get a hold of that. If you don't, know it inside now, right.

You need to know what you're against, what you need to meet. Then you need to-- lots of you start to learn more about some of the security features built-in to the device and we're going to talk about that today. That is, what are those features in this new device? What is it that you can leverage immediately to help meet those policies? First and foremost, what we want to help you understand is how to take this iPhone from factory fresh to corporate compliant? How do you get it that way, OK? So again we're going to make our way around these quadrants. We're going to start with physical integrity. And before I do that, I kind of wanted to bring up this quick notice to most of you. By now, since it's the end of the week, you should be aware of this.

But with iPhone Configuration Utility 2.0, all new stuff here, not only are you getting much more kind of granular policies that you can apply here, is that for many of you one key aspect has been that you can now prevent the removal of that. Once it's applied to the phone, prevent the removal of that unless you wipe the device, right. In many environments, before you could get the configuration profile applied but then the user would remove it. In your environment where it's very strict, you needed to be sure that it wasn't removed.

With 2.0 that's an important part. So we're going to be referencing different pieces of this throughout the session. So physical integrity, right, what are we talking about? We're talking about accessing this machine, protecting from unauthorized access to the phone. What does that entail? Think about, first of all, the pass code protection, right. Right on the screen you get out fresh out of the box, things that are available to you.

You do the enforcement of the passcode, you got the length. You do things as a simple PIN. You got history there and automatic lock, you know, you kind of automatically lock the screen. And then the ten failed attempts where if it fails, then it automatically wipes the data, right. That's kind of an out of the box experience there.

So you're seeing a lot of slides there. OK. Now, with 2.0 we've given you that ability to now do that by policy, right. You're extending this and the bracketed areas towards the bottom here are really kind of the ranges that you have available to you in the iPhone Configuration Utility.

Of course, depending on where you are in that kind of security sensitivity range is where you're going to fit within the range for each one of these, for instance, the complexity. If you're in a highly sensitive environment, you may make that four. If you're not so highly sensitive or this is kind of in your work group area, you might stay in the lower end.

Again, this is kind of talking about things you need to think about. The failed attempts, again that gets back to if your device is out of your hands. Somebody attempts to try to do that. What's the range that you feel comfortable with before that device gets wiped? Again, all in 2.0.

Those of you that leverage Exchange ActiveSync, add that additional capabilities with the passcode enforcement from that side adding a lot to what we have, in addition to what we just talk about with local in our password-- or iPhone Configuration Utility, OK. You get all the additional capabilities with passcode enforcement. Now, again, think of local. We're thinking of physical integrity here.

The local restrictions or we just think of restrictions on the phone. So for 2.2 that you had, you've been able to lock things down, prevent it from going to the App Store if you're in an environment where you don't want additional apps installed, even the hardware, right, the disablement of the camera. There's many environment where when you're in a facility, you can't have the camera or a device that has a camera in it. Nice thing, right.

Now, you can lock that down. So you-- restrictions here is up on the third, the 3.0 version. We even added location, gave you in the in-app purchase control. Now you get more functionality in the phone and you've got more ability to lock all these things down if it's appropriate in your environment.

So with the iPhone Configuration Utility here as well with the 3.0 side, now you have the ability of these restrictions on the policy side before you had it directly on the phone. OK, nice again being able to force by policy the camera in many environments. I think if any of you have come to WWDC year after year, we've done a lot of kind of security best practices for OS X in that environment and any devices in all of the organizations. Frequently, one of the biggest challenges is dealing with all kinds of environments where your devices are used, right.

A lot of us go to hot spots.

A lot of us go to other network environments where we don't control the network, where that be Wi-Fi, Bluetooth, that kind of stuff. So this is typical security best practice you you'll from anywhere and that is if you're not using a service, it's always best to disable things, always best to just turn it off if you're leveraging it. OK? Again, it gets to that lower quadrant of the unknown. What you don't know, you don't know. And of course, a lot folks kind of nicely leverage our built-in Airplane Mode, do that and instantly you've disable the radios as well.

So, think about the SIM as well. You've got a SIM chip in the phone, so we're talking about iPhone and iPod Touch. So in the phone you got the SIM. Also consider the fact of adding the PIN on the SIM itself, right, kind of a second level protection at least on the server side. And the fact that there is, all kinds of data physically that you're accessing another services.

Other environments, you've got stuff on a SIM right? We even give you the ability if you had SIM and all, just sends in. I'm not personally familiar with a lot of folks that have gotten some of the context stuff on the SIMs but you've be able to import that.

I've seen a fair amount of folks put lots of sensitive information or content. So think about displays on the front of your phone. Have you ever been in a meeting or been somewhere and somebody sends you a message and it displays on your screen and it may not be appropriate at the time, OK, that's kind of the personal side but what about confidential information as well, right? This is-- if that's a probability of an issue in your environment, go ahead and just turn off the SMS display off.

Again, it's being able to control the unexpected that you don't have kind of the timing control. And when it comes in-- and this is really more so for extremely sensitive environments in largely government and things like that. There are a lot of folks in that place that have to deal with knowing whether a device records as well.

So be aware of the fact that you can go ahead and do some recording on this device as well, right? It's just something to be aware about. I've been in several meetings, even in the last couple of weeks where you had to leave devices outside the room just because they could record. So again, that's just something to be aware of. So as we talk about this maintaining integrity around, let me turn things over to Michael Brouwer and we're going to look at application integrity. What Apple is providing in the phone to help protect on the applications side. Mike.

Thank you Shawn. So application integrity. What we're doing on the phone is we're trying to protect applications from modification. And doing so, through couple of different technologies and first of all we're doing code signing which ensures that application is actually the same application that the developer built on his machine when the application running on the device is the same application to develop or built on a machine and hasn't been changed since the developer for-- developer compiled.

Other technology we're going to talk about is sandboxing which ensures that one application can't get at the data of another application and that application can't modify sensitive system information as well. In thirdly, I'm going to talk about distribution. Obviously, we have distribution to the App Store but there's also distribution for-- which is probably more interesting for the people here which is distribution of the custom IT applications to users that aren't getting distributed through the store.

So code signing. Why do we do code signing? Well it's-- to ensure that the application hasn't been changed. It prevents the application from being changed after it's been installed. So at install time, we verify the entire application but every time you launch an application, every time a code page of an application is loaded into the memory, we check that that code page hasn't been tampered with.

And doing so ensures that no virus or other modifications to the device could cause that application to behave unexpectedly or at least behave differently than the developer wanted it to. So what it won't do is it won't prevent the application from doing something wrong if the developer compiled it with, you know, malicious code in there already or if there were just bugs in it. It also-- code signing also doesn't protect the data part of the application. We're only signing code pages.

So we're not signing any resources your application might load or NIBs or tips that, you know, graphics that it might load, et cetera. And it also doesn't protect network traffic. That's up to the application to use the appropriate APIs to do that. And if your application is accessing data on the network, it's up to you as the developer to make sure you do appropriate authentication first.

So in addition to signing, to the code signing part, we have to determine whether or not to trust a particular application and whether or not to allow it to run. And there are two ways that an application can be allowed to run on the phone. One is if it's developed by a third party and signed by Apple which is applications loaded to the App Store are that, are signed that way.

So developer builds the application, you sign it with your code signature, send it to the App Store. The Store goes through its bidding process and assuming the application is accepted, Apple re-signs the application and puts it up on the store. So when someone downloads it, it's signed by Apple, and therefore it's trusted to run on any device.

Second way is when someone develops custom applications-- custom in-house applications and those are signed with regular developer identity. And the application doesn't get re-signed. Instead, you need to install a provisioning profile onto your phone to allow that application to run. Now, that provisioning profile allows you to trust additional applications in addition to the ones that are just on the store and it does so by allowing the identity that was-- that signed those applications to be trusted to run applications on a particular device. In addition, provisioning profile can contain a white list of devices on which that profile is valid.

So that means that you can control on which subset of devices your applications will run. So if you have a sensitive IT application, even though that application leaked out that people outside-- people outside of that white list can't run that application. The profile itself is signed by Apple and you obtained it through the developer portal. And application, like I said, is signed by your in-house IT department. So once you have the provisioning profile, you can develop new applications and new versions of your applications and deploy them at your own pace.

You're not, you know, we're not a middle man anymore at that point. So what are some of the benefits of doing the code signing because-- so one of the thing-- one of the main reasons we started off doing this when we went from the, you know, 1.0 iPhone OS to the 2.0 iPhone OS, when we opened it up for applications is we wanted to limit the amount of ways that rogue code could enter your device and essentially make your phone unusable.

I mean everyone knows about, you know, all the problems of different deskstop OS's today. And by having code signing, it significantly raises the bar for code injection exploits in that the way the iPhone OS is architected, in order for a code page to be marked executable, it has to be backed by a signature. So there is no way the kernel will allow you to make something executable unless it's part of the assigned applications. So that raises the bar for, you know, viruses and other types of attacks significantly.

Of course, it doesn't protect against social attacks, or like I said before, you know, correctness of the third party app code itself. It can't protect against bugs that were already there. And since code signing doesn't cover data, it also doesn't cover data driven attacks. So modifications to the data could still potentially be exploited.

So talking about the data side, we have a second technology called "sandboxing." Now, sandboxing is-- one of the technologies we use for sandboxing is Mac OS X seatbelt technology and what we do is we try and give each application the least amount of privileges it needs to be able to do what it needs to do. So the standard seatbelt profile for third party apps allows your application access to its own files but not access to any other third party apps files and it allows access to a limited set of shared system files.

So what that buys us is it constrains access so that you can only access authorized data and it prevents you from accessing or prevents an application from accessing resources that shouldn't be changed.

So application can't directly get to some of the, you know, config settings or how to talk the GSM network for example. So, I talked earlier about distributing your applications and the different ways you can do that, and this is for applications you've built not through the App Store.

So, you need a provisioning profile and an application to be installed on the device. You can either use iTunes to do this or you can use the iPhone Configuration Utility. iTunes were automatically push both the config profile and the app to your phone or sync them to your phone. So that's what we've recommend for most users since most users wouldn't be using iPCU.

So, the way we distribute this with iTunes, and this is assuming you're pushing the profile in a managed type environment, if you have a managed machine, if you don't have a managed environment you can just tell your users to download the profile, drag it on to iTunes and it gets installed. If you're in a managed type of system, you could actually install those profiles with a script or with whatever management system you use in one of the following directories.

So, the user's home directory, there's a provisioning profiles directory where iTunes looks and there's a system-wide provisioning profiles directory as well. And you can override the place that iTunes looks for those profiles by changing, what is it, preferences key. For the applications themselves, as the user drags them on to iTunes it gets added to their library and it will sync.

Now here is actually the same paths and example for Windows, on Windows it's the same thing. For the apps, you just drag them on the profiles, again, can either be dragged on or we can-- you can programmatically install them in one of the following locations. So, I'd like to show this in action. Alright, so you see the provisioning profiles are not here in iTunes, we'll re-sync the device.

Alright now we have, the app is on the device but the profile's not there anymore, and as you see the app no longer launches. So if we go back and install the profile, and we can do that either by dragging into iTunes and just for the sake of this demo I wanted to drag it into the directory pretending we're a managed system, installing that profile there. If I re-sync the phone, and see, the application launches again.

And here we go. So, sorry about the little hiccup [applause] [laughs]. So, what you saw there was that in order for the application to run on the phone, it needs to have both the provisioning profile and the application there. Because the provisioning profiles actually authorizes that app to run.

And so, the provisioning profiles and the apps can be both be distributed in, you know, whatever way you feel like as long as your users have a way to get to them and it's actually easy if you have a managed setup to already pre-install those profiles on your users' machines so they don't have to worry about the profile part of things. And with that, I would like to bring us on to the next section, and just talk about Data Integrity. And for that I'll bring Shawn back up.

Thank you Michael.

OK.

Thanks a lot.

Side here. Now we're thinking of the physical data that you're dealing with on a daily basis, right? When it comes down to it, that's the most sensitive part, right? Apps, we've all got but we all have our own data whether it's personal or corporate.

So we're looking at what do we do to protect modification or disclosure of that data. So we're going to look a little bit about certificate-based trust. We're going to talk a little bit about the encrypted backups now and the data that rests physically in the phone and on your computer side.

And again, heading-- relating this to the application piece itself. So first of all, many folks are sometimes curious to which certificates are automatically trusted on the phone. Keep in mind that we keep that in sync with Mac OS X. The best way-- or there are two ways to look. If you-- just a visual person, you want to quickly look at list.

If you look at the system roots on Mac OS X, that's the list. If you truly want to see a separate very voluminous document, go up to the K-based article and you'll see every single certificate contents listed out. And then of course, many of you are going to need to push out and put your own corporate anchors because most of you have kind of your own server certificate, you're going to need push out your own anchors to your machine, to your-- ultimately to your phones.

So the configuration profile here of course is the appropriate way to do this, right through the credential's panel through the mobile config file. Do these as email attachments. Many folks were doing that early on, sending out the certificates within their corporate environment. Users are either on Wi-Fi within the organization, they get their e-mail. They install the certificates that way and of course downloading it from a website, so. When you're thinking of the phone, say some of this is education, some of this is just thinking of normal practice.

If I'm on a phone and I go to a site and I see the fact that I can't establish a connection to the server for various reasons. Why they can't-- it either can't validate the cert or it just can't establish a connection, right? If this is within your organization, first and foremost that should have been step one within your configuration profile to be adding your corporate certificates, right. That way the user's not dealing with that. Now, you always get to the point of-- if we didn't have any users then we wouldn't have any problems, right. So the other part is training.

If your users are outside of your control and they're going to websites, first and foremost, if they do that, if they go to a site, kind of some external site and they see that kind of thing, first reaction is you probably shouldn't connect, right. But connect with caution, right.

If you're sure that that truly is the site, you can proceed but proceed with caution. So again, largely that's typical user training if it's outside your control, but if it's inside, it's your server, if the certificate is related to you, truly you should be putting that inside your configuration profile and handling it upfront. Next, think about data at rest on a computer, right. Now you've got your mobile device but you've also got backups of that on your computer. And so now with iTunes, you've got the option of doing the encrypted backup of what's on the phone, right.

So what is physically on your phone that does the backup as Michael is going through here, you saw iTunes doing the backups. Physically now, that's storing it, encrypted data on the-- on your computer, right. Of course, you can do the standard entering of the password and store that in the-- your Keychain as well.

For those of you that like to tinker or need to know where all this is, this is physically where it's located. So within the user's library directory, and note that that's really the device ID in there, within there you're going to see blobs and lots of files related to the data itself, and the corresponding manifest and all for that. So that's where it's located.

If you really want to tinker around and say, "Yes, Apple did encrypt it." So you check. OK. So now, some other approaches to think about. Think when the phone first came out, a lot of people were doing just web services. Some of the best environments still, any concern with data is, keep the sensitive data on a server, right.

Not all applications require that you put all the data on the phone. Many folks have some incredible applications on the phone where all the data is always on the back end. They're doing real-time access, partly, because the data changes. So, maintaining a secure connection to that web service and accessing data in real-time, from kind of your back end servers, that's a great way of ensuring that you only keep sensitive data on the servers and nonsensitive data on the phone. OK, that's one way.

Another way is all the applications that you're developing or that you're moving onto your phones, you've got the ability of doing the encryption of that data within that app as well, right. That's always been very much available to you and other developers to apply that to each individual application for storing a password in the Keychain app. So now, with the new phones, with 3G S, we're providing to you and all the end users the ability with the hardware encryption, right.

This is a great new way to help take this further.

Couple of things to keep in mind with that. First of all, it's always on. That's a great thing for those of you that have to meet compliance regulations. What I mean by that is, some of the best or-sorry, some of the most difficult things within kind of IT management is to prove that your policies are enforced, right. To prove that all your devices are meeting the compliance. Well, if it's always on, there's nothing for you to do, right.

There's nothing for you to configure. There's nothing for you to have to worry about. It's on all the time. And so if you think about the performance numbers and battery life and all, that is taking consideration that, again, it's always on. It's all the users' data, right. That's the important part. We talked about the applications. Michael went through about maintaining the application integrity. It's the data there. That's what we're fully protecting. And of course, it's strong encryption, it's this 256-bit AES.

Coming in the 3G S, love to have it in my hands now, coming soon. OK, many of you redeploy lots of your devices and I've seen quite frequently the redeployment of laptops, desktops, and even mobile devices where lots of sensitive data just went to somebody else, OK. So when you are redeploying, this becomes almost more sensitive than when you've got a device fresh, right, because now there's potential for all kinds of stuff on it. So first of all, think about the local wipe.

OK, that is you've got the ability of doing a local wipe where they do the failed login or failed authentication side or just the initiating of local wipe. So on the previous phones, takes about an hour for every 8 gigs to do that erase. So if things die, you know, it's good to always have things plugged in if it dies. It's going to keep going when it gets powered back up. And the 3G S is instantaneous wipe. So again, when you're meeting compliancy, you know that you initiated that remote wipe.

So when you're thinking again of this redeploy, you can do this. I just mentioned about the remote wipe from the exchange site, much like the passcode, additional passcode policy enforcement, you could initiate that remote wipe from the exchange site as well, so, 2007, 2003 way is here, then the new ways with MobileMe, right.

So this gives you the ability of initiating that assurance that you tell the device to go ahead and do that wipe. Now, we want to go take this further to our kind of our last quadrant on this and that's on the user integrity side. And for that I'll bring up Mitch Adler. [Applause] Thank you, Mitch.

So I'm going to talk to you a little bit about user integrity. We consider user integrity ensuring users get exactly the access they should have. This typically applies to the device wanting to communicate back to your home servers, your services that you want to give your users, and how you prove that this device belongs to a particular user. We have two sets of problems we're trying to address. The first is establishing users' credentials. You know, is this person really who they say they are, authoritatively. And protector his credentials while they're sitting on the device.

Some of these credentials don't actually reside on the device in an attempt to protect them even further but often those end up being passwords that users simplify to the point where we don't even consider them secure. The other half of the problems we're trying to address are problems that you and enterprise IT space have which is protecting your services from unauthorized access and giving you a solid basis to have credentials established from our phone. At the same time, we're trying to support industry standard verification methods to enhance our ability to fit into your existing environment.

Some of the forms of credentials we support on the phone are simple passwords, mail and calendars support simple passwords, the sense of being a shared secret that usually user knows and can be given away. So it has some shortcomings, but many of our systems support it. You can make the user experience better by allowing the user to save the password on the phone.

We have one-time passwords used mainly on the VPN, 802.1x configurations on our phone. This requires the user to enter the password every time they want to use their service which means with our communication devices that keep bouncing on and off networks that really hassles the user to say you want to get back to that service you were using 10 minutes ago, now that you've picked your phone up again. So we don't typically like to recommend this even thought it's a viable technique in there. And if your security needs call for it, you absolutely should consider using one-time passwords.

We prefer X.509 digital identities. These are useful in VPN, 802.1x. Safari can handle it using the client-side auth in the 3.0 version. 3.0 has also added the ability for our Microsoft exchange services to use X.509 digital identities for their user authorization. To go a little bit deeper into what an X.509 identity is, many of you probably already know this, but an X.509 identity is actually two parts.

It's a certification of somebody's identity that takes a public bit of information and identifies who the holder of this key is and what the permitted usage of that key is. And the private part, which is the secret that is used to prove that I'm actually the holder of the secret key.

So when I present my certificate to somebody else, they can challenge me and say are you really you, and I can prove that I'm me. You can see examples of the pairs on our desktop Keychain access. If you go in and look under identities, you'll find often public certs and potentially the private keys if you have possession of them on your system.

So in order to use these identities, I actually have to make it to your device. In 2.0, we have three methods by which you could deploy your identities to your device, all of which are based upon wrapping identity in a PKCS 12 file and securing it. And all three of these mechanisms could take those so you could web host a PKCS 12 file and you can import it on to the user's Keychain. You can send it to him via mail attachment and you could also send it to them in our configuration profile via iPhone Configuration Utility.

In 3.0, we've added a new mechanism to be able to deploy identities. It's direct enrollment from the iPhone. It uses the Simple Certificate Enrollment Protocol, SCEP. There was a session yesterday that went to rather great detail on iPhone configuration creation and deployment. And if you're interested in more detail on how to implement this and the IT side infrastructure you need in order to be able to do an SCEP server, I suggest you go and check out that session online. It has great detail on it.

One of the examples of us using the identities, and in this case, using SCEP drive data identities is VPN on-demand. We at Apple are already using VPN on-demand and enrollment of identities for our VPN access for many of our early adopters of the 3.0 software. Basically, we deploy an identity through the configuration profiles to actually request to get an identity from our servers.

When you install the configuration profile that goes off to our servers, enrolls your public key in our VPN system and stores that on the device and then configures our device to use the new feature of VPN on-demand. So when I pick up my device to get my mail, it automatically invokes my VPN, proves it has my private key connects to our network, and gets my mail, which is pretty damn cool in my opinion. There's one more opportunity I wanted to talk about.

If you're building an application that's custom for your environment and you want to explore some higher security or different authentication techniques, there is an opportunity for you to take advantage of some of the new features that we've just put in 3.0. We have the new extensible IP technology where you can have your own custom protocol and you can do this both over Bluetooth and over wired connections over serial connections on a 30-pin.

And if you have a need to have an app that has strong two-factor authentication on external device that can-- that actually controls the keys for this particular application, using the open-ended protocol, the custom protocols you can put in as a good opportunity for somebody to build an application that does this third party-- this external two-factor authentication. And with that, we'll go back to Shawn and let him sum up about our four quadrants of integrity.

Thank you.

So thank you guys. So we've kind of gone around the horn, got a couple last minute things. But hopefully, this has given you a really strong foundation to take back, of knowledge to take back to your organization to know how to get the iPhone to fit in to your corporate regulations, fit in to your infrastructure.

Now, this was kind of a quick intro and it really was leading in to some of really what the session was on the configuration, creation and deployment session which was yesterday that Mitch had mentioned. So really refer to that, but keep in mind that when you're doing the whole profile, configuration profile, and moving that to machines, and moving that to the phones, it ultimately comes down to the old kind of carrot and stick thing, right.

You want to be able to give someone access, but if they get access, they play by your rules, right. You kind of do that management to what's appropriate in your environment. But one typical thing that folks will do in a single configuration profile is all of your credentials, much like we've been saying.

That could be a single one and you might lump together everything else into one large profile, enforcing passcodes, enforcing some of the other policies that you need to meet.

So many of you would have seen this as well in that same session. So, again, it's a great asset to you now to be able to do that over-the-air enrollment using a SCEP with the new systems.

So what we've taken in through here, first of all is, anytime with security, right, you've got to balance your needs with risks, then that's where you try to determine what policies, what a different configurations you need to make, what adjustments to make it fit. But, hopefully, we've exposed you even further. This is the end of the week here at WWDC.

But hopefully, we've exposed you further to some of the additional security components being both hardware and software built-in to the current and coming iPhones and iPod Touches, and then how to do that secure distribution and managing in with the policies. But most of all, hopefully, we've given you adequate kind of tools to your tool belt, so to speak, of going back and now taking the iPhones and deploying them within your environment.

Again, hopefully, regardless of what policies you have. We always like to end these sections with where to go for more guidance. Much like I said in the beginning, security is a constant battle. There is no way that we can say that when you walk out this door, you're now secure because there are more challenges, right. You constantly maintain the stuff. So, first of all, many of you should have seen iPhone in enterprise, kind of the landing page for all this.

We have lots of folks that are already deploying iPhones that are-- have looked, you know, scrutinizing the iPhone and how it fits their environment. They all have different risk environments. They all have different challenges that they face, a great place to be starting with kind of your own pursuit of background information what you need to deal with.

And there's going to be more profiles out of there as well. Of course, there's always our enterprise landing page as well for the iPhone. And, of course, if you're on the developer's side, staying up with all the iPhone development is key-- a key resource going forward. Again, with all of our security guidance along the way, and this is really-- I guess, I mainly somewhat talking to the higher security focused folks, more so in government, some other environments. We've been collaborating but very closely with several of the government agencies specifically on providing security best practices. So this is not just simply Apple saying what it is.

It's a collaboration, actually, all the people involved in there-- or agencies or Apple, we deal with national security agency, with NIST and with DISA. So all of us jointly work on collaboration with giving you additional guidance, you know, kind of the full written guidance on there. And within the federal space, there's ongoing work that will come out to help with guidance in the phone as well.

Work going like I just mentioned here and then it's even with FDCC for those people that are familiar with that, the Federal Desktop Core Configuration that carries over to handhelds, to mobile devices. Again, that's largely geared towards even typically US government folks. OK, lots of resources. It's ongoing, so we hope that this has really given you some good background, kind of added the tools to your belt.