Good afternoon, Ladies and Gentlemen. Welcome to Session 602 about configuration profiles, creation, and deployment. My name is Stan, and my question is are you in the right room. We were talking about it -- there's going to be two kinds of people coming to this session. Those are who are IT professionals and those who are lost. So if you're an IT professional, this is the place to be.

Otherwise, I guess you can wait for the beer bash here. It's nice and cozy. I have one question before I start. Who has been to the same session a year ago, because we have some things that are the same, some things that are new. Okay, so about half. Half is new.

So what are you going to learn. We'll be talking about what we call managed configuration, configuration profiles on the phone. What are configuration profiles, what can you use them for. We'll be talking a little bit about a profile format, how to create a profile, and how to deploy them.

So what are configuration profiles. They are small XML files that host a lot of settings that can configure the phone. They are typically used for things that would be considered cumbersome to set up on the phone, where you don't want your average user in the company configuring the VPN and what not.

They can also enforce a specific set of policies on the phone, the type and length of the PNG code, auto lock time, et cetera. They can do all of this securely, especially now in iPhone 3.0. We'll be talking about that more. This is not to be confused with provisioning profiles.

There is nothing in common with provisioning profiles. There was a session about that earlier, so if you're looking for provisioning profiles you're at the wrong place. So in version 3.0 of iPhone configuration profiles configure many things, more things. There's some things that we have improved and some things that are new.

I'll go over this quickly, because a lot of it is the same as last year. First of all, Microsoft Exchange. You all know what Microsoft Exchange is good for. E-mail, calendaring, address book, and also security enforcement. Lots of policies get pushed down from Exchange. Now in 3.0, also the camera off, more policies that I'm not going to talk about in great detail. And we also have cert-based authentication so that you can send the whole profile with everything ready to go to the user.

We have passcode policies and restrictions, you define a set of passcode policies, they're applied in conjunction with the EAS policies, they're merged together so that multiple profiles each can specify a policy, and then the most strict will be applied. And the merging goes as follows -- imagine you have one profile or one EAS account that specifies I want six characters passcode. I want the passcode to expire in 60 days or 30 days. The other one says, you know, just four characters is fine, but you have to have two special characters.

The merge profile -- the merge policy is going to be as listed below. Credentials. You can install profiles -- you can use profiles to install certificates or you can install raw PKCS#1 and #12 certificates on the phone. That way your organization can install signing certificates on the phone to be used for your own profiles and what not else. Also for authentication identity, such as for EAS.

We'll be talking about that more in great detail. VPN configuration. You know what VPN is, various protocols, and now in 3.0 we support also proxies. We have Wi-Fi settings. All the leaps, peeps, beeps, and what else, eeps -- and basically anything that you can think of, 802.1x. Application access restrictions. We have added some new policies, most specifically Camera Off. That has been requested by many companies to be able to turn off the camera. That can be specified both by in a profile and by Exchange.

Mail settings. Host, protocol, all that good stuff. And now you can embed the account password as well. Not just in the e-mail accounts, also in any -- well, many other payloads would logically allow you to specify a password. We can do that now because they're encrypted. So you're not actually transferring the passcode in the clear, we'll talk more about that later. And APN settings. My favorite, you either know what it is, or you don't want to know.

You also don't want to play with it if you don't know, because it will turn off your data access on the phone, which is typically considered bad. Now in 3.0, you can allow -- specify an HDV proxy. Web clips. One of those things that came actually as a suggestion from our customers here at last year's WWDC. Web clip, you know, is in Safari. You press a plus button and you create a shortcut on your Springboard desktop for the page your currently have open. So now you can push that as part of a profile.

You can make them optionally nonremovable, and it's useful, for instance, to go to your company's IT web site and what not. SCEP settings. Now we're going to go talk more about that later, but in SCEP service, you specify basically two things. The URL of the service, name, and then also the input to the certificate signing request. We'll be talking about that more, where that's being used.

And then your good old friends, LDAP, CalDav, and CalSub. So LDAP, you know what it is. It's a DirectoryService that's being used for completion in your mail, Address book, and what not. CalDav, it's the OS X Server's Calendaring solution, it's for wireless synchronization, an SD engineer who works on that particular feature, says it is a lot of fun. And finally we have CalSub. Calendar subscription, that's -- you can download those calendars from Apple or Google, you can optionally authenticate with user name and password. So those are the combined features in 3.0. Now we're going to be talking to great length about details.

So the profile contents are flexible. Profile can configure any single component, what we talked before, or basically virtually any combination of, you know, APN and VPN at the same time. That's for convenience and also for a carrot and stick approach, so I give you access to the cert-based VPN.

But at the same time you also have to comply to my password rules. Now as an improvement to last year's slide show, we now have a donkey. Carrot and stick. So you give the user something he or she wants, and you made him obey by your rules, like for a travelling salesman, no explicit music and what not.

Content restrictions. So there are some restrictions. You can't really combine everything you want, there are some rules on that. So you can have only one passcode policy per profile, you can have only one application access per profile. Only one removal password per profile. We'll talk more about that later. And you can only have one EAS account globally on the phone, whether you enter it manually or in a profile. It's also all or nothing.

So you can install a profile as a whole, and you can remove a profile only as a whole. So if for some reason a profile can't install, because there's some errors, nothing of the profile will get installed. So again, you're dealing with the complete package of the carrot and stick.

The password -- the profile removal is also regulated so you can optionally make it password protected, or just flat-out make it impossible. Be advised that's typically rude, and it might be flat-out illegal if the user actually owns the phone. If your corporation owns the phone, you know, it's your phone.

But the user owns the phone, it might not be really legal. So now going to security and authentication, authenticity, you can sign a profile so that it -- the user can see whether it comes from somebody they could trust or just any XML editor. So we have three types of profiles. There's signed and verified, so they can be traced through a well-known route. You have they are signed, but you know, I just make up the certificate. Or they are unsigned.

So the user sees right away based on the badge how trustworthy it is. Basically, it's the same signing as we use in OS X, and we have about 600 root certs that can be traced to. So now new in 3.0, profiles can be encrypted, obviously one of the most requested features that if somebody intercepts a profile it's like gibberish. They can be and they should be always signed, even if they are not encrypted.

All encrypted profiles are also signed. And that means that you can insert sensitive information in your profiles. You can put e-mail passwords in there, you can put EAS certificates, authentication certificates, VPN and authentication certificates into the profile, because they're encrypted. So -- and if you omit some information iPhone is still going to ask you for that. So there's some caveats. There's still no dependency analysis when removing a profile.

So if you remove a piece of information such as a certificate in one profile, it might render a different profile unusable. There is still no conflict resolution installing a profile that overlaps with a previously installed profile, will typically lead to an installation error, and the profile cannot be installed. And there's no expiration date for profiles, per se. Certificates still have expiration dates. So it's possible that, like, a piece of the profile, the certificate will expire.

But the profile in itself will not. So the profile format is the same as last year, except we enriched it. It's standard XML. It's the same DTD as in OS X platforms. And the format is really, really simple. We use the same keywords all over the place, and the specification is published.

Now how do you create the profile. Well, you can do it by hand or you can use iPhone Configuration Utility. Which now new is for OS X and native for Windows. We no longer have the web iPCU, we now have a native one for Windows. The iPhone Configuration Utility serves as a curator for all of your configuration and provisioning profiles and applications and many other things, creates configuration profiles very easily.

It encrypts and signs them. And interesting for IT people, it also allows you to download the console for debugging. For instance, when a program doesn't install, it can attach it to iPCU, and the console is going to tell you why. It does many other things, but we're not going to go into those here. So on that note, I would like to invite Chris Skogen who will show you -- will give you a demo of iPCU.

Okay, so you need --

Thanks Stan. I'm going to give you a really quick demo, tour, of iPCU, or iPhone Configuration Utility as it's formally known. Before I get started, since we are all IT professionals, I'd like to see a show of hands for how many people use Windows on their desktop every day.

It's okay, you're amongst friend, you know, nobody's going to -- so this will be kind of a first for this demo. We are actually going to do the demo on Windows. So as we're looking at iPCU, it has a pretty typical Mac interface. On the left side, over here, we have a source list and it contains the different types of sources for our library. Over here on the right is then the Detail View for the sources that are in that library.

And then the bottom pane is our detail or editor pane for each of the things we are looking at. Starting at the top of the library if I click on the devices source, you will see a list of devices that this iPCU has seen connected to it. It can show you the name of the device, serial number, identifiers, owner's name, and in the bottom detail you get a summary of the device with identifier software version.

And it will also show you configuration profiles that are known to be installed on that device, it will show you provisioning profiles that are known to be installed on that device, and it will also show you applications that are known to be installed on that device. You may wonder how we get a device in there.

It's as simple as connecting it to the computer, just like iTunes. And you'll notice in the left-hand source list in a second, you'll see the device pop up, just like iTunes or Xcode. And in the device record list up here we now have a green light on that record to tell us that that device is currently connected. If I click on the device itself I get a slightly different look to the editor. I also get configuration profiles, summary information, provisioning profiles, applications.

But then there's the console log that Stan was mentioning. And I can see everything that happened on that device's console, and I can select them and save them off. After the device list we'll take a look at the provisioning profiles. Now provisioning profiles are the files that are used to make your device able to run a given application. And I have a couple of demo files here. All I do is drag them.

Now the provisioning profile editor will show me the expiration date, the application identifier that the profile is for, and then in the bottom, it will show me any phones that I have in my library, and it will show me whether or not I have installed that profile on the phone.

In this case, Lucy's phone does not have this profile. Now if it was a matter of wanting to install that profile I would go back to the connected device, go to provisioning profiles on this tab, and there's my Install button. So that's how I go ahead and install a provisioning profile on a device. And of course with provisioning profiles are applications. And I can add a few applications to this library.

Just by dragging and dropping. And again, this editor will show me devices that I know of and then it will show me whether or not this application is on that device. And it's similar to provisioning profiles again. I can click on the connected device. Go to Applications, and go ahead and install that application.

In a demo in a little bit we're going to show you installing configuration profiles on the device, but for now I'm going to focus on how to actually use iPCU to create a configuration profile. So what I do to get started is I select the source list for configuration profiles.

I go up to the toolbar, and I press the New button. Now I get my new profile here with a default name, and the bottom editor is our new configuration profile editor for 2.0. On the left side in this list you will see the different payloads that Stan was going through.

And on the right side when I select a payload, I will see the state of that payload and all the data for it. So I'm going to run down some of these payloads quick, and while I'm doing it, I'm going to be showing you how to create a configuration profile for kind of real world usage. So let's assume my company's name is Acme Inc., and I'm going to create a profile that has VPN access to my company, and in addition to that, I'm going to enforce a passcode.

I'm going give the user a web clip on their Springboard, and I'm also going to take away some capabilities from the device. So let's get started. I have my new profile here, and in the general payload which is always there, I get to specify the name of the profile.

So I just click, give it a name. I'm going call it Acme VPN profile. Now I have to give it a unique identifier. These identifiers are very important because when you are updating configuration profiles on a device they are uniquely identified by this identifier. So in this case, I'm going call it com.acme.vpn. In the future if I want to change that profile I have to have that same identifier, and it will overwrite it.

The organization name is Acme Inc. and the description, which will be shown so the device when the user tries to install the profile, Acme Inc., VPN configuration. And I'm a bad typer. There. Down here at the bottom of the general payload is where you would enable or disable removal of the profile. By clicking on this you could say allow it to be removed with authentication, or never allow it to be removed.

For this, we're going to leave it as Always. The user can remove it. So for the next payload, which is a passcode payload, you notice when I click on it, I get this little gray screen that says this payload is not in the profile. So in order to start, I actually have to hit configure to add the payload to the profile. Once I've done that I'm presented all of the options in the payload.

And you'll notice in the right there's a little minus button which is remove the passcode configuration. So if I hit that it will go ahead and remove that payload from here. What we want is we want to require a passcode on the device, and we do not want it to be a simple value.

So we don't want it to be 111, or AAA. And that's really all we're going it do for the users of this Acme VPN. But you'll see there's many other options for minimum number of complex characters, how long before we lock the device, how many failed attempts they can have before we'll lock the device. So that's it. I leave that one , and that payload is part of my profile. Now we'll take a look at restrictions. Now I said I wanted to stop our users from doing some things on the device, and specifically, I don't want them using the camera.

So I'm going to uncheck these. Now, I got that backwards. I'm sorry. I'm going to allow them all of these, and I'm going to take away the use of the camera. Again, there's nothing to do, just move onto the next payload. That one will be saved. We're not going to be adding Wi-Fi to this payload, but I'd like to show you the Wi-Fi editor. I go ahead and add the payload by pressing the Cconfigure button. You'll notice on the Wi-Fi that there's a plus and a minus button.

That's actually because I can add more than one Wi-Fi payload. So by clicking on plus, you'll see that it added another configuration for a second Wi-Fi. And in here you'll find all the different types of Wi-Fi set ups that can be done, all the eeps , peeps, TLS, authentication by certificate, things like that.

So I'm going to take this payload off because we're not going to use it for Acme Inc.. The next one up is VPN. This is one we are going to use for Acme Inc.. I can give it a connection name. Acme VPN connection. I can choose the type of connection.

We're going to keep it very simple. We give it the server name, the little red arrow goes away indicating that that was a required field. I can give it a user account. And since I'm going distribute this profile encrypted, I can go ahead and put the shared secret for the VPN in there. That's actually it for VPN. You also notice I have the plus sign so I can configure multiple VPN payloads.

Moving on to e-mail, we're not going to use that, but very quickly. Here's how you set up the e-mails, there's the incoming, outgoing mail servers, all the different, you know, server name, server address, you can put in the user name and password. So we'll take that one out. Here's the Exchange Active Sync settings that Stan was mentioning earlier. The domain, the host for the Exchange Active Sync.

We're not going to use that, we'll take that out. Some of the new settings. LDAP. Similar to the Wi-Fi and VPN. You can set up multiple LDAP servers, you can do your search settings down here, and your host name and password if you're going to be deploying encrypted profiles. Another new payload for -- for 3.0 is CalDav. Again, just like the other ones, add your host name, ports, account, user name, password, use SSL, and you can add multiples. Subscribe calendars.

Similar. You're seeing the pattern by this point? Here's the web clip that Stan was mentioning, and we are going to put this one in our Acme. So we're going to call this the Acme HR portal So because they're going to take our VPN, and this is our carrot and stick approach -- because they're going to get our VPN, there's the carrot, stick is going to be they're going to lose some functionality.

But we're also going to give them this quick web clip to get to the HR portal inside of the company. So we can say this is hr.acme.com. Whether or not the user can remove it from Springboard and whether or not you're going to -- you add an icon here for the Springboard by either dragging and dropping or by hitting Choose.

And you can add multiple web clips. Credentials is not new. This is how you would actually put certificates and identities on the device for usage n Wi-Fi payloads or VPN payloads, things like that. SCEP is new. This is how you can do an enrollment protocol for getting certificates to the device over the air. And there's going to be a demo of that later on in this presentation.

And then here's the APN payload and advanced settings for the new HTTP proxy and things like that, that we're not going to be using that. There, I've run through all of my payloads, and I have my name, the description, the organization, my identifier, I've enforced a passcode on the device, I've set up my VPN, I've given them a web clip to an internal portal, and I'm done.

So now the next step that I would want to do as an administrator is start to deploy this to devices. And at this point my demo is done, but we'll turn it back to Stan and let him start explaining how we roll out these configuration profiles. Thank you.

Thank you, Chris. Okay, switch box. Chris, [Inaudible] here we go. Slides A. We did not rehearse that part. So that is Chris. Okay, so now we created a profile. Now we need to deploy to the people, otherwise, it's kind of useless. How can you do that? The good old way, via e-mail, via the web, and now new in 3.0, we have the USB tether from iPCU and the really sexy way of doing it is the over the air, just no strings attached, distributed to people remotely.

The USB and OTA approach are always encrypted. You have no choice there. The e-mail and web you do have a choice if you do want to go encrypted or not. Typically, we will say that in most cases you do want to go encrypted, but there are some reasons why you might not want to do.

For instance, the simplicity of it is one. All encrypted profiles are device specific. And so if you wanted to deploy a profile to say, a whole university with 10,000 students, you would have to have 10,000 very unique profiles for each phone. And that might be overkill for a profile that just, you know, gives them a web clip.

That might not be suitable. So it's all about how much effort you want to put into it. So the old way. Click on the web. The profile gets installed in preferences. May or may not be encrypted. It's very easy to deploy, just put it on the server. You can distribute a URL via e-mail or via SMS. You can password protect the web site itself, but not the profile.

If you want, for some medium security. You should set up this MIME type if you're planning to deploy to 2.X devices. In 3.0, if you're deploying only to 3.0 devices, you don't need the MIME time. The phone, when it sees .mobileconfig will do the right thing. Extra credit if you know what aspen stands for.

The other old way of doing it is e-mail. You can push it to a user's e-mail account. It requires that a user already has an e-mail account. So it can be quite out of the box. The profile can be encrypted, but doesn't have to be. Note that neither of those devices, approaches, rather, are a true push.

The user still needs to press the Install button and go ahead and install the profile. New way. Distribution via iPCU USB push. So as we -- Chris already showed and we'll see more demos of that later, you connect a phone to a computer and you just press the Install button as you can see in the screen shot above, and the profile will get installed.

But still, somebody has to confirm and press the Install button. Or, the new sexy way, profile deployment via OTA. Your iPhone just talks to a cloud in the sky, and it's fully encrypted, it will require some sort of auto authentication, like some sort of password that you already have set up with the company so the device can do a handshake with the server with your OTS server, to agree that yes, okay, I trust you, you're one of our friendly phones.

And you still have to tap to install it. Don't file requests that you would like a totally automatic push this profile and it has to be installed. We know about that. And if you actually think about the problem, it's harder than it seems because the generic general case cannot be solved without user interaction. So if you really want to know what's going on behind the scenes I would like to invite Conrad and, yeah, go ahead.

-- the encrypted profiles, and also the profile distribution service. So that you can actually get them to there. Because obviously setting up an encrypted channel with the phone is going to require a little bit more than just -- I don't know, guessing. So I'm going to basically talk about encrypted profiles, you know, how did we get there, what -- how do we actually encrypt them.

Then I'm going to go over the high level steps that we go through to have them distributed from a profile distribution service, and how we get the phones set up with that service. And then at the tail end of it I will actually show you a demo with like a little Ruby server and Raccoon, and just show you basically, you take a couple of pieces of software, you put that together, you can actually get your own solution going.

So encrypted profiles. First of all, as Stan has already pointed out, these things should be signed so that your users can see, like, hey, this profile is actually -- wasn't tampered with when it was in transit to me. And signing them is actually really simple. It's just take a profile and turn it into a CMS signed data. You know, there's nothing secret or special about it.

It's fairly simple. It came to us that other people had thought that maybe there was something special about it, but this is it. Then of course why are we having these encrypted profiles. Well, we want to install some policies as well as some services, and those services will then have some keys to, you know, the magic parts.

You want them all installed together because basically if you give people access to your local network you want them to abide -- at least a passcode on their device, just to make sure that, you know, when they leave it in a restaurant, no eone will be reading their e-mail like, within, 30 seconds. So how do we increment them.

Well, sample answer there too, encrypted profile is just really that array of payloads that you're going to install. All stuffed into a CMS envelope data, and all of that then goes higher up into an XML file and -- well, the server will basically give you a technical look behind the scenes as to how that actually is put together, and you should be able to just make it work from there. One thing that's also mentioned, of course. When you pick encryption, we are encrypting toward a specific device. So you do have to have, you know, a specific profile for each device. You cannot just share those between different devices.

And that brings me kind of to why we needed that profile distribution service. So let's talk about that for a bit. Well, if you want to set up a profile distribution service, obviously there's this enrollment part where, you know, a user picks up their phone and wants to start using it.

So the first thing to do is figure out, like, okay, who is this user. If we're going to be specific, then you can also install all the services and configure them for this particular individual user already so that the only thing they have to do is install the profile and they're off.

Second of all, you probably also want to figure out, hey, what is this device. Is this actually an iPhone, what software is it running. More about that later. So then we need the profile service to get, you know, the phone has to get enrolled so it can prove to the profile service which phone it is.

And so that the profile service can actually provide the encrypted profile for this particular phone. And after the phone is set up that way and it comes back and says, like, hey, give me my profile. The profile service can now go ahead and figure out this is the user, this is the device, these are all the settings that should go together.

Let's put them all into a profile and send them off. Of course if later on you find that, you know, some settings are wrong or something needed to be fixed, the same way the phone can now come back through that same profile service and go ahead and pick up a new profile that is going to just wholesale replace everything that was there before, and the user can keep going at that point. So I skipped quickly over this certificate enrollment. This didn't exist on the phone before, so with 3.0 we actually now have a form, a way of doing certificate enrollment. And for CMS we're going to need some X.509 identities.

So what we did here is basically add enrollment so that we have a way of avoiding the key ever leaving the device. With enrollment, what we do is we generate the key on the device, we send the public key off to SEA, and then basically they can give us back a certificate with which the profile service can now identify us and send us encrypted profiles targeted specifically at that device. For that we use SCEP. The request will be pre-authenticated. This is to make a seamless experience for the user so that basically they go through this install step and it just goes going, keeps motoring on.

That enrollment, then finishes for the profile service. But you know, this feature enrollment, you could also use if later on you decide to set up a VPN client base -- client certificate base VPN in the configuration. So you can have it used for these additional credentials, that on install it will go ahead and enroll a couple more entities for the various services that you want to provide. So couple words about SCEP. It was a practical choice for us because it basically allowed to do that automatic enrollment.

And the profile service will use that in a way to prove to the CA that, hey, this request that you're going to get actually should be handled, and you should basically give out a certificate. It is limited to RSA, but so are we. So this only goes for RSA key pairs and X.509 entities. And then you have the choice of picking 1024 or 2048-bit keys. One thing to be said about 2048-bit keys is, like, nice big secure.

But they take a while to generate on a device, especially older ones. So you may want to find -- strike the good balance between picking maybe a smaller key size and you know, having it valid for a shorter amount of time, which also reduces your risk. So the challenge for pre authentication needs to go in there.

So you need to set up a way by which you can have the profile service prove to the CA on the other side, because the phone basically gets all these details, turns around, talks to the CA, and says, hey, enroll this public key for me. So you have to have a way to have both of them agree that this should be done. And so the profile service has to provide something that the CA can then validate to see that it should issue this a certificate, yes or no.

Another thing to mention is as we were building the solution at Apple we do use this to deploy on demand VPN for ourselves. But we implemented our own solution to basically mesh better with the architecture of our IT organization. So in that, we missed a couple of small interoperability issues that we actually need to still fix. So if you have an existing SCEP server, you can actually go ahead and use that one instead, you don't have to hack up something because you already did the work. So with that, let's -- I wanted to also quickly touch on USB versus OTA.

It was already kind of mentioned that as soon as you get more and more profiles that it can get out of hand. But at a high level, both function the same way. With USB tether you obviously have the trusted connection already, so there's no need to set up, like, a web service and make the phone actually talk to it securely so much any more. You can basically have them quickly negotiate the secrets on the first tether connection, and then later on you can actually send encrypted profiles over e-mail, or you can actually put them on a web server as well.

The updates do have to be pushed, and a profile service, the phone can go ahead and it can just go back to profile service, say hey, give me a new one, and that will happen; in the iPCU case, you will have to generate them, put them somewhere, and then ask the user to go ahead and download the new one. So as you can see, it's a little more involved up front to set up OTA, but it will scale to more devices, which, you know, eventually you have to make a decision there. So the overview of how this is going to go.

I'm going to quickly touch on the various steps, then we're going to go into a little bit more detail, and then finally I will actually show you that this works and what it looks like to the user. I mentioned the profile service and I mentioned SCEP server. I'm actually pulling them apart here just to make it a little more clear that there is a profile service that does all the handling of the profiles, and then it can turn around and have the phone go ahead and talk to certificate authority to enroll that certificate.

So first of all, we need to get started here. What can you do? Well, let's make this simple. A URL would be the easiest way. You can use an SMS to send it out to the phone, but this starts with a URL. That should make it relatively easy.

Then the phone has to go ahead and authenticate. Possibly the user, but the device as well to the profile service, and see if it's willing to let it enroll. If things go well, the profile service will now give it enough information that the phone can go ahead and enroll in the profile service. And get a profile service certificate, that is. Then it can go back to the profile service and say, well, I'm enrolled. Here's my certificate.

Where's my profile. Gets the encrypted profile, and as a final step, the phone will go ahead and install that profile. And may actually find additional certificates it needs to go ahead and enroll. And as such, it can go and complete those steps with the certificate authority before all the services get configured.

So first step. The boot strap. We have a URL. We can go ahead and send out the HTTPS request to the profile service. At this point we have the option of authenticating the user, making the user use whatever authentication Safari supports, and have them put in user name and password.

The profile service can now, you know, start keeping track of, like, who this user is by adding an authorization token to the payload it's going to send back. It's going to send the device a payload saying hey, the profile service is at this URL. Here's the device attributes I'd like you to tell me, so tell me what kind of device this is.

And it will also include that challenge to basically point it to which user authenticated in this step, so that in the next step we can basically put all of that information together as we get ready to enroll that profile service certificate. So to authenticate the device, the device goes ahead and picks up all these device attributes that are required.

It can tell you what build it's running, it can tell you what device, it can give you the unique device ID. It will sign all of that with the device certificate. Again, this is a CMS signed data, trivial thing to check. And this way you will know, because of the device certificate, it's an iPhone, and because of the contents, what version it's currently running.

As a result, the profile service will say, like, hey, that looks good to me. Send the SCEP payload to the device for it to go ahead and enroll a service certificate and off we go. So what does that look like. Well, that's the SCEP step. You can read about that elsewhere more specifically. But in short, the device generates the key pair.

The key pair goes into a CSR, [Inaudible] and all of that gets sent in an SCEP request to the certificate authority. The authority can then pull out that challenge, can check, hey, is this little challenge here, was that actually signed by the profile service? Yep. It was, okay, good.

Go ahead, issue that certificate. Send it back in an SCEP reply. The phone will go ahead, verify that reply that they got it back from the service that actually asked for a certificate. And we're done. So let's get an encrypted profile. Well you see the same step again, really, as the previous time. The device is going to go ahead now and send the device attributes, but this time it's actually going to use the profile service identity that is now acquired.

It just got that profile service certificate, put them together with the private key, there you go. You've got a identity. So we sign the device attributes with that identity. Send it to the profile service. The profile service can now look at that certificate and identify the device. And can go ahead and prep that specific configuration for the device, encrypt it for the device, and send it back. So one thing to mention about this step is this is not only the step during which you get the first profile, and this will also explain why we're sending these device attributes again in this step.

When the phone comes back, say a month later or so, and one of its identities has expired and it needs to get a new one, it will send you the device attributes again. So you can recheck what version of the software are you running now, just to, you know, figure out what services you should have access to and which ones maybe not. And then the final step. We get this encrypted profile. You can see the policies with the services and the credentials.

They're all packed together there. And they all install in one go. And obviously, your keys to the castle here are the credentials. But the credentials don't necessarily have to be included, as I said. They can also be generated at this point, and then the phone can go off during install and go ahead, put together an SCEP request, go ahead get that certificate enrolled, stick it into the configuration. And move along. And with that, I finally get to the cool part. Now going to demonstrate how this works to you.

And the thing that I'm going to demonstrate to you is -- we have a phone. I'm going to demonstrate to you a service that was basically put together with a simple Ruby service, and -- I'm going to steal the sticky-tape here. A simple Ruby service, and a Raccoon running on my laptop, which is also the profile service. So it's kind of an all in one service.

Just to show to you that basically you can -- I'm glad that they got less fingerprints on the new models, because this one is horrible. Yeah, you don't need those. So as you can see, we can get to this profile service here. This is the first time I'm actually connecting to it. This profile service goes ahead and sets up its own self signed certificate because it is going to have to issue a whole bunch of certs to the -- nice -- okay.

There it is. I don't know why I plugged that in. That's only going to get iPCU involved in this as well. So we don't want that. One step I already did here and I'm actually going to quickly show you this. Since I have a self signed certificate here to start out with, I needed to make the device trust it, because this is basically going to be the root of all trust. It's going to be the thing that issues the VPN certificate is going to be the thing that issues me the profiles and all of that.

So what I did was I went ahead and installed the profile service root certificate here. And with that, basically the phone will now trust anything that was issued from that CA going back on down. So going back to the profile service, we have the root certificate on there.

You can basically boot strap your process by getting an actual certificate from a CA and get started with that, then go to an HTTPS web site and pick up the organization's root certificate from there. In my case, I have to kinda you know, dance around and say it's all good.

Now let's go ahead and enroll. So this is the first boot strap URL. I'm not typing in the URL in this case, I'm basically going ahead and just going into the profile service. After all of this I have already done user authentication which Safari helpfully remembered for me from a previous time, so you haven't seen that either. The service will of course, you know, prove to you how you can make that work. The profile service comes back and says hey, this is a profile service, would you like to get enrolled in this one? I say, like, sure, let's do that.

And now an awful lot of things are going to happen at once. Because we're going to enroll in this profile service, which is going to ask us to go ahead and generate a key pair. Then go to the SCEP service in the background. So get that certificate enrolled. Go back to the profile service.

Say, like, hey, where's my encrypted profile. And it's slower than normally so I've got a little chance to tell you what's going to happen. The profile service that you see now is going to switch into the actual encrypted profile. You see that the screen changed to secret layer. So now I'm going to have a configuration profile to access that.

In the top you can see that now we're actually going to go ahead and generating more keys and enrolling more certificates, because if you look at the contained section you'll see that we're going to install a web clip to point us to where the secret layer is. We're going to set up some VPN settings to do a client-side certificate off to a VPN server on my machine. And then there's an SCEP payload because we're not including the client-side entity in the payload yet, we're actually just telling it, hey, go ahead and get that one enrolled.

Could have shown you that there's more here, and if you can see the top -- this view is not that friendly. But you can see that I basically got a profile service issued certificate. And that actually got used in my VPN crossing the moat. Configuration. So let's see what we have. We can go back to Springboard and you'll see -- oop, there is the new web clip to the secret layer.

And that will basically be a URL that I set up to have on demand VPN launch and use VPN to go -- to get in there and then hit the URL. Obviously I stopped the demo short a little bit here. What's going to happen is it's going to bring up VPN. It's actually going to ask me for X off user name and password, because I don't have enough Raccoon food to turn that part off. But at this point we will already have negotiated with the client-side identification.

So what you will see will go to the URL, it launches Safari, there's a URL that doesn't exist. Then the VPN says hey, X off. But we're not requiring that part. And there we go. There's the message of the day that was installed on the Raccoon service. This is the best I could do to prove to you that I'm connecting to my VPN server there, and okay. And as you can -- may have noticed in the top there's the little VPN icon that came up.

So it's going, and if we go back to our configuration now in general and in networking you can see that we now have VPN set up, and there is our profile. One thing to note about the VPN profile is because everything was managed, we're not actually going to let you change anything about it. You can turn off the on demand switch, but that's all you can do. And with that we can get out of there.

Now you can see, we've been connected for 45 seconds. Wow. So going back into the profiles I wanted to show you one more thing. There's now two profiles. One is the root certificate authority, and the second one is the actual configuration profile that you've already seen before. I marked it as it's already expired so I can show you what's going to happen when something goes wrong with one of these identities, if VPN at some point kicks you out and says, yep, that's no longer good.

You end up at this screen. And there will be a button at the bottom where you can say, hey, go ahead and update this profile. And then it will tell you, like, hey, I -- you know, existing profile could not be updated. But I can get you a new one.

Would you like a new one. I'll say, like, sure. And it will go ahead. And now we're going to get a new one. And notice that VPN icon at the top, what's going to happen is it's going to uninstall the old configuration profile, then install the new one on top of it.

Of course I should have told it to go install and replace in the meanwhile, while I'm talking. But basically what you're going to see is the VPN icon is going to be pulled down because I just removed the configuration. And now we're going ahead and generating a new key just for the VPN client off, and then we're going to go ahead and enroll that certificate again, and then at the end of it I should be at the same point as I was.

You get a good feel for what happens when you demo to some stage. If you generate a couple thousand 24 bit keys, the first couple ones are really -- go really well because you have lots of entropy, and then you slowly run out. And there we go. We finally generated the key. We enroll it. We're done. Go back, there's no -- you see, there's only one secret layer icon. Yeah, yeah. There we go. And there's VPN again.

Go -- I'm so happy to be back. All right, last step. We're going to go ahead and remove this just to show you that it cleans up nicely. I didn't actually demo you, like, restrictions in here. This could have basically asked me for a passcode, like, right in the middle of doing this install to tell me like, hey, you don't have a passcode yet, I want you to install one. I didn't include that here. That would have probably been nice to show you.

But I'll leave that as an exercise for you. The profile service we're going to be at that lab afterwards. You can get that Ruby file from me and you can even peek at some of the Raccoon notes if you like. But that Ruby file should basically be like your best attempt as a technical piece of documentation for you to figure out a service like this yourself.

Then if we go back here, let's quickly look for VPN, because hey, it's no longer configured, all right. And just to prove to you that this wasn't all fake we can try to reload this URL again, but you know, it's just not going to go anywhere. Okay, we do that.

Anyway, with that I want to turn it over back to Stan.

Thank you, Conrad. So this was one of the reasons why I was asking initially were you in the right room. This is the really new way to deploy profiles. It really scales well. The whole USB tether thing is great for small shops, when you don't want to set up a server.

But this thing is really great if you have several people, if you have, you know, 100 people it will be hard to get them all to your IT person's cubicle and connect and do things. So now we have installed profiles. Now what are we going to do with them. Well, one of the things is they need to be backed up.

Just this last year if you back up a device and then you restore it to the same device just because you erased it or something like that, the profiles will be there. If an encrypted profile has been installed on the device via USB or e-mail or whatever, either way, if it's encrypted it will require an encrypted back up in iTunes. There's a new feature to optionally require encrypted back ups. If you have an encrypted profile, you have to have encrypted back ups, or it will not allow you to back up your phone. There's no migration.

That's in a way a security feature for open cubicle landscape. Prairie dogging is good, stealing other people's configurations and secrets is not. So if you take a phone or you buy a new phone or you go out and buy the 3GS and you have profiles installed on your old phone, you back that up and you push it to the new phone, the profiles will not come across, the Keychain is not going to come across as well.

So you have to reinstall those by hand. Updating profiles. So Conrad was showing there, that, you know, he pressed the Update button. The Update button is available only when you hit an OTA installed profile. If for some reason your IT organization pushes out a new profile, and again, there is no real push in 3.0, but when they tell you hey, there's a new profile available, the update works roughly as follows -- you navigate or you get an e-mail to the same profile again. You press Install. It so to speak deinstalls the old profile and puts the new one in its place.

All of this is triggered by the profile identifier. When you look at the XML documentation of the profile or when you look at the iPCU, there's that one identifier thing that's the most important thing, has to be unique. So you can have unique identifiers for your Chicago, San Francisco, what not place. And if a new profile that comes into the device has the same identifier as something that's already on the phone, that whole thing will get uninstalled, the new thing will get replaced. It will be placed in its place. We were talking about security a lot.

And you know, that you can't -- one of the new things is that you can't update a profile with another one that does not come from the same signing authority. Because for instance we were talking about nonremovable profiles, we'll talk about that and we'll show you more about that later. You flag a profile as nonremovable. Well, somebody could issue himself a profile with iPCU that you can download off Apple's web site that doesn't have the nonremovable flag set, and it would just supercede it. And then you could remove it.

So that would kind of be a joke. So in order to install a new updated profile it has to come from the same signing authority. Removing profiles. Again, normally unrestricted, but then can be flagged as nonremovable. My plea to all of you is be really careful with that. At least provide a removal password. We have encrypted the profile so there is a place in iPCU where you can enter in a password. It will be encrypted. Nobody's ever going to see it.

And then the IT person can give to the end user, hey, the password is fubar. And it may be flat-out illegal. So think about that. So enough talk. I would like to invite the other Chris who ironically is other Chris's roommate, office mate, on stage, who is going to show you the user experience.

Hi everyone, I'm Chris Pavicich, I am along with Chris Skogen one of the other iPhone Configuration Utility engineers. And I'd like to talk to you today about the on-device experience with configuration profiles. So I'm going to go ahead and install a couple of them from an e-mail. And I'm also going to show you doing a tethered install with iPCU.

So bear with me for a second while I get set up. So here's my iPhone. I'm a new employee at Acme Incorporated. And my System Administrator e-mailed me out a couple of configuration profiles. So I'm going to go into Mobile Mail, and I see that Chris sent me a couple of configuration profiles to help me get started.

I'm going to go ahead and install this first one. And you see that Mobile Mail actually when you send mobile config files as attachments, recognizes them, and it knows how to handle them. So I'm going to go ahead and I'm going to get started with installing this profile. And I'm just going to tap on it. Launches the Settings app. And it brings me to the Install screen. And we get a nice summary, the name of the profile.

This one hasn't been signed. A description. This one's got some web clips in it. When I received, I got it today, and it has three web clips. But I'm going to see more details about the payloads in the individual profile. I can tap More Details. I see that I'm going to get three web clips. I'm going to get access to our wiki, our lunch menu, and our main web site. So that looks pretty good to me.

I want to go ahead and install that. So I'm going to tap Install. So an alert pops up here letting me know that this profile wasn't signed. So the authenticity can't be verified. And it's also letting me know that installing this profile is going to change some settings on my device. I'm good with that, I really -- I want these web clips, so I'm going to go ahead and tap Install now.

It's going to do its magic. Lets me know the profile is installed, and I'm done. Takes me back out to Mobile Mail where I came from. And let me show you actually that it did install those web clips. So I'm going to hop back out to Springboard, and you see it added three new web clips to my Springboard desktop. Chris also sent me another profile, I think with some Wi-Fi settings in it so that I could access the corporate wireless network while I'm in the office using my phone.

I'm going to go ahead and install that too. So yeah, there's my Wi-Fi profile. I want to install that. Go ahead and tap on it. Again, it will launch settings automatically. Bring me to the installer screen. And you see that this profile summary screen is slightly different from the last one in that it shows me who signed this profile.

This one's been signed. But it's not been verified. So I don't -- the phone in this case doesn't trust the CA that signed this profile. But it has been signed. And again, I can see what's -- payloads are in this profile, there's a Wi-Fi network and a restriction. Let me see what those are. It looks like -- I'm not going to be able to use YouTube if I want access to the Wi-Fi network.

And that goes back to the carrot and stick approach Stan mentioned earlier. You may need to give your users access to VPN, Wi-Fi network, and there might be certain rules they have to play by, whether it's passcode restriction, they can't use explicit content, they can't install apps on their phone. So I'm pretty happy with this, I want access to the Wi-Fi network.

And I'm willing to deal with losing YouTube. So I'm going to go ahead and install that. So again, I -- it tells me -- the authenticity of this profile couldn't be verified. Installing this profile is going to change some settings on my phone. And once this profile has been installed on the device my System Administrator has locked this profile down and said that the only way to remove it is with an administrative password. That was embedded in this profile.

I'm okay with that, I really want access to the Wi-Fi network. I'm going to hit Install now. As Stan mentioned earlier, if you leave any information out of a profile that's necessary for it to work, the user will get prompted for it. I already know my Wi-Fi password, so I'm going to go ahead and enter it. Tap Next. The profile installed. And we're good to go.

So as I mentioned, this profile was locked down, so you had to have a password to remove it. And I want to show you what that looks like. So I'm going to go back out to Springboard. And as you may have noticed in the earlier demos the application on the device that manages the configuration profiles is the Settings application.

So I'm going to go ahead and launch Settings. Go into General. Scroll all the way to the bottom. And I see I have two profiles installed. I'm going to tap that, I'd like to see what they are. There's my web clips one that I just installed, and my Wi-Fi. And I'm ready to take the Wi-Fi off. So I'm going to tap that. Hit Remove. And I have to know the removal password for this profile, and I happen to know it. Tap Remove.

It's going to pull the profile off. And my access to that Wi-Fi network has been removed. I can do the same thing with the profile that installed the web clips. And when you uninstall configuration profiles, it takes anything it added to the device with it. So we saw that there were three web clips installed. When I removed the web clip profile it's going to go ahead and delete those as well. So let's do that. Remove. Yes, removing this profile is going to change some settings on my phone.

I'm good with that, I'm done with the web clips. Take them off. And no web clips. Cool. So that's -- as we mentioned, there are four ways to get profiles to the device earlier. OTA, from the web, delivered via e-mail. And the fourth one is via tether to the iPhone Configuration Utility.

So in just a second here I'm going to -- and we'll go back to iPCU. I've got a VPN profile that I'd like to install on this device. I'm going to give some of my users access to the corporate network remotely. I just drag and drop that file on to iPCU.

And -- I'm going to change the security on this VPN profile to Never. I never want my users to be able to remove it. So the only way they can get those configuration settings off of their device is to either wipe it and reinstall the OS, or bring it back to their System Administrator and say please remove this configuration profile from this device.

So it's essentially locked onto the device. And one important thing to remember is that when you add a profile like this to the device, one, you should do it sparingly, because it can be a real hassle for users, and two, it can only be removed from the iPCU that installed it. So I'm happy with this configuration.

Make sure it's all good. There's my VPN settings. I'm going to add a bunch of restrictions. No Music Store, no apps, I'm really locking this guy's device down. I'm going to go ahead and select my connected device. And again, you get the Summary screen. Configuration Profiles. I'm going to go ahead and install my VPN profile.

I'm going to hit -- [Inaudible] since I can't show you both the laptop and the device at the same time, and I want you to see the device experience, I'm going to show you that. All I'm going to do here is tap Install. Tap Install. It's going to push the profile over to the device. You see that because this profile came from iPCU, and when the device was connected to iPCU they swapped security credentials. This profile is now verified. So the phone trusts it.

Go ahead and tap Install. And now we'll get a different warning than I got before. The one before said once this profile is installed it can't be removed unless you enter a password. Slightly different verbiage here. Once this profile is installed it can't be removed at all. I'm good with that. I really need the VPN access. So I'm going to go ahead and install it. And I need to enter the VPN password because I didn't include it in my profile. I need to enter a passcode now.

My profile installed. And I can go ahead and -- oops, there we go. Profile installation is done. Click Done. If I go into my Settings I see that it added a web clip. Oops, General -- Network -- I'm not connected to my VPN. Now let's go back and look at what that nonremovable profile looks like in the profile settings.

So I'm going to launch Settings again. General, Profile, and you notice there's no Remove button here at all. This is locked to the device. Like I said, you either have to wipe it, or you have to remove it with iPCU. Still connected to iPCU. So I'm going to go ahead and I'm going to remove this profile from the device. So the UI updated when this device was attached. The profile is installed. And what was an Install button has now changed to Remove. I'm gonna go ahead and tap that. Yup, I know that this can't be undone. That's cool.

I want to remove it. See that it's now available to install. Now that it's been removed. And if we go back to the device, again, go into Settings, General, and Profiles is gone. There are no profiles installed on this device. So I've shown you today how profiles are installed via e-mail, how the different security settings show up in the Profile Summary screen, and the different security restrictions that exist around configuration profiles. Thank you for your time, I hope you have a great conference.

Well, thank you Chris. Now for the last few slides. That was the user experience. Let's have a few words about best practices. You have seen four ways of deploying profiles. Use OTA for the best flexibility and the best scalability. It is some up front cost to your IT department, but it is by far the best experience for the user.

Because they can be anywhere, they can be travelling, they can lose the device and get a replacement device, and it will still work. But it is some cost for you to set up the server, and we will help you with that. USB with iPCU when you have a small shop, when you have just a few employees.

Or just for debugging. That's also really useful. Use unencrypted profiles when you just want to share something that there is no secret. Just web clips for universities, that's how the whole idea was born. And always sign profiles so that the user has some sort of a certainty where the profile came from.

The profile will refuse to install -- the iPhone will refuse to install the profile that has been tampered with, or where the signature doesn't match. So the summary, the profiles are here to simplify life and configuration of phones. Because most users don't want to deal with Exchange and VPN and Wi-Fi and all that.

iPCU is your hub how to create and also how to deploy profiles Encryption is available here now as a big thing. Everything that you have seen here is totally secure, sniffing the channel is not going to do the hacker any good. Even if they were to download the profile from the phone, it's still stored encrypted. You can distribute profiles over the web, e-mail, or OTA and USB. And always consider security when creating profiles, and choosing the deployment method.

For more information, if you have any questions, bug Mark. Not us.