Good afternoon, everybody. I'm Ken McLeod. I'm an engineer in the Data Security Group where we work on Keychain and I'll be talking about the Keychain today. as soon as I can get this to work. So the session basically will start off with an overview of what the Keychain is and what it does. And we'll talk to you about the new features that are in town with the Keychain. I'll go over the Keychain manager APIs that are available for your application to use. And the last thing I'll talk about is the whole area of managing user interaction with the Keychain.

And at the end, we'll have a demo of the Keychain with Mac OS X and time So the three main questions that this session is designed to answer, the questions are: What does the Keychain give me? And how can I add support for it to my application? And of course, where can I get more information about it? Feel free, as the session goes on, to sort of add your own list of questions that you can ask at the end if you have more that the session doesn't cover.

I've got here a key chain. This is a key chain in the real world. And I apologize for, you know, right off drawing a distinction between computers and the real world. But I'll try not to do that too often. But the real convenience and usefulness of this thing in the real world is that I don't have to remember these things individually. I don't have to remember to bring, you know, my car key with me, my office key, all these things. I just have to remember one object. I have to remember to bring my keys.

And then I have access to all of the services or the things that these keys unlock. And the same idea is true of the key chain on OS X and on OS 9. The idea is to provide something that is a convenience, but much more than a convenience, it needs to be secure.

Because when you're letting your computer manage your keys for you, you need some level of security. So that leads me into the definition of what the key chain is. The key chain is a secure repository for your passwords, your digital keys, sort of analog on the computer of what the keys are in reality.

A much more appropriate metaphor perhaps than even a key chain is a sort of bank vault. The bank vault has a door. And when that bank vault is locked, the things that are in it are locked down. You can't get out them. They're protected. When the door is unlocked, there's a security guard sitting there and he's monitoring all access. He's checking the credentials of everybody who takes a key out of the vault.

The Keychain is built on something we've been talking about called CDSA, the Common Data Security Architecture, which as of this week is all open sourced. And all of the work that the Keychain does happens down in that layer. CDSA has a whole series of plug-ins for doing things like data storage and cryptography and those pieces are all part of that framework that you can take a look at.

The Keychain has a convenience feature, as I said, where clients of the Keychain can provide something called transparent authentication. In other words, the user experience of typing in your password once to unlock your Keychain and then not having to type in all the passwords that are actually stored in the Keychain, so you have a single sign-on user experience. As Craig mentioned to start off with, the Keychain is available on both OS 9 and OS 10. But on OS 10, every user has a Keychain. Every user logs in, they have a user account, and a Keychain is automatically created for them.

So I like to define terms when talking about the Keychain because it can get a little confusing. What do we mean when we use the word Keychain? And there's a grammatical difference here between Keychain with a capital K and Keychain with a small k. When we use Keychain with a capital K, we're talking about the technology. We're talking about the software that's built into the operating system. When we talk about Keychain with a little k, we're talking about the data store, the thing that the user has that they put their passwords and keys into.

The Keychain can be in one of two states. Keychain is either locked or unlocked. And the definition of an unlocked Keychain is one that has a key which is available to decrypt items in the Keychain. Without that key, nothing can be decrypted, nothing can be retrieved from the Keychain, and the Keychain is locked.

Everything that you put in a Keychain, whether it's a key, an actual cryptographic key, a password, a certificate, we use the term Keychain item to refer to all of these things collectively. And the other term, the last term that we use a lot is Default Keychain. The Default Keychain is if you have more than one Keychain, this is the one where items are added to.

So, typically, a user logs in, they have a keychain created, but you're not limited to that as a user or as a developer. You can create as many keychains as you want, have as many unlocked as you want to be unlocked at a time. If you want, you can set a keychain to lock automatically. By default, the keychain will be unlocked at login and locked when you log out.

But if you want to restrict that even further, that's completely available to you. The default keychain, again, when you log in on OS X, is unlocked and it's got the same username--or I'm sorry, the same name as your user account and it uses the same password as that account by default. Again, you're not limited to that. You can change it at any time, but this is just sort of to give the user a default keychain. default keychain.

You can take a Keychain and move it around from machine to machine. And what we mean by the word "portable" here in this context is that you can take it from one machine to another, you can take it from home to work, vice versa, so you have the keys with you on any machine that you use.

Portable in this sense does not mean portable between 9 and 10. Now the reason for that is that, as you'll see when you look at the CDSA pieces, we have open sourced all of the algorithms that the Keychain uses. And on OS 9, we had some algorithms that were proprietary and could not be open sourced, so we moved away from using them and we moved towards something that could be open sourced for OS 10.

You can put Keychain files on a server so that you have them available. You can put them on a CD. You can just use them wherever they happen to be. And the CDSA architecture doesn't limit us to that. It supports, fully supports Keychains being on smart cards or removable tokens so we can actually get back to having a real world Keychain that has a little removable token that actually holds your digital keys.

So here's a diagram or a map of all of the APIs that are available across the board related to security. Starting on the left-hand side there, an OS 9 and still available in Classic are the Keychain API and an API that we talked about previously, Macintosh file signing, and some other ones there. All of these are built on top of the older version of CDSA 1.2, which had quite a lot of limitations, but worked well for OS 9.

Moving forward, your applications on OS 10 will either use Carbon or they'll use Core Services. Now the Carbon piece sort of straddles the line between the two implementations of CDSA and the two platforms. So if you write an application that uses the Carbon and Keychain APIs, you can run on OS 9 or on OS 10 if you're a CFM binary.

So, what kind of items can you store in a Keychain? Well, there's three basic classes of items that are defined: keys, passwords, and certificates. On OS 9, keys and certificates were there. For the first release of OS X, we focused on getting passwords really supported well.

Certainly, keys and certificates are something that we are working on, but the focus of what I'm going to talk about today will be passwords. And within the class of password item, there are three sort of categories. We have Apple Share passwords, which allow you to access Apple Share servers.

Internet passwords are a more general case for any type of You know, protocol like SMTP, FTP, what have you, those sorts of things that require, you know, access to a server. And then the last category of password is sort of a generic password account and service type of item.

So let's drill down a little bit and look inside a Keychain item. A Keychain item's contents are really simple. There's two things: there's attributes and there's data. The data is, in this case, the password. In this example, just the data of the password that I'm trying to protect.

I can add a number of attributes to the item that help me find the item later on. So if I'm storing, for example, here a password for an FTP server, I might want to add my account name and the name of the server and some other information that lets me find that password item and match it back up when I need to log back into that server.

So every item that's in a Keychain has a set of common attributes and all these items can be treated more or less the same. They have the class of the item, they have things like the date when the item was created or modified, they have a label. describes the item. There's also a description of the item.

There's a comment field where, with the Keychain Access application, a user can actually add comments to an item that's stored in the Keychain. Within those subcategories, though, of an Item class, there are additional attributes that are defined. So, for example, if you have an Internet password, you have things like the protocol and the server, which are additional attributes that are specific to an Internet password. And the whole purpose of adding attributes to these things is so that you can find the item again when you're looking for it.

Now the data portion of the item is protected, as I said. Unlike attributes, you can't search on the data of the item, so it can't be revealed to you in that way. The data cannot ever be retrieved unless the Keychain is unlocked, and it can't be retrieved unless the user gives explicit permission.

Now, I'll get into that a little bit later, but in OS X and with CDSA 2.0, we're able to let the user or the administrator configure the access control on a Keychain item and have that be persistent. And in the case of cryptographic keys, private and symmetric type keys, the data of those items is actually never able to be retrieved from a Keychain. You'll only be able to use item retrieval. references to reference the item.

So, the data of an item is protected and it can't be retrieved unless the user gives an explicit okay. Now on OS 9, some of you have seen what this means. It means that a dialogue comes up. The dialogue says, "This particular process is trying to access this item.

Is that okay?" And the user at that point has to make an explicit decision, "Do I want to allow this process access to the item?" On OS 9, there was a problem though because that dialogue box kept popping up every time you accessed an item and it got really annoying because there was no way to securely store that setting persistently so that after you rebooted the machine or you came back, the same thing wouldn't happen again. You wouldn't be asked again for permission.

On OS 10, CDSA lets us have access control lists that are persistent for an item. On OS 11, we have a keychain that can avoid or give permission once to a particular process. What we'll do is store a hash of that process and later when that same process tries to access the keychain, we'll say, "Okay, yes, this is the same process you're allowed to access without having that dialogue pop up." The application or the process that puts an item into the Keychain by default has access to it on the philosophy that, well, you know, they have the data that they're giving us, so we'll trust them to access it. And that prevents a lot of unnecessary asking of the user for permission.

So, every item in the Keychain can have its own access control list and you can configure these individually. Allow any application to access a particular item or you can restrict it to just one application or a whole series of applications. You can use the Keychain access utility, which is available in the Utilities folder, to preconfigure access.

And, I will show you a little demo of that later. The access control APIs are available in the CDSA layer. We don't currently have any in the Keychain Manager API to configure those. We assume that the user or the administrator of the machine will set up the permissions as they see fit for a particular Keychain item. And of course, access control lists stick around on OS X. So, you know, across reboots, it's always going to be there.

So what can you do as an application developer with the Keychain? Well, the first The most important thing is you can store things securely there in the Keychain instead of perhaps having to worry about how you are going to hide a particular piece of data, whether you're going to encrypt it yourself, put it in a preferences file, whatever. We provide that now as a system service that you can just take advantage of and not have to worry about it.

You can also look in the Keychain when you need to connect to a particular service so the user doesn't necessarily have to type in their password more than once if that password is available in a Keychain and the Keychain is unlocked. So if you are connecting to, let's say, an FTP server, you can look first in the Keychain to see if there is a password for that FTP server and use that instead of having to force the user to type in a password every time.

And another thing you can do with it, you're not just limited to passwords in the traditional sense, you can use the Keychain to store, for example, cookies or software, you know, perhaps serial numbers, registration numbers, maybe a content key for, you know, an MP3. There's just all sorts of little bits of data that need to be kept private by your application and now there's a central place that you can store them in a secure way. Amen.

So, here's the sort of high-level overview of the API. There are two, uh, There's sort of divisions. There's high-level calls and low-level calls. And it's real easy to get started with the high-level calls because there's really only two. You'll find a password or you'll add a password if there isn't one already there.

There's a series of low-level routines on which those high-level routines are built. And so they give you the flexibility to do perhaps a piece of what the high-level routines do without requiring or pulling in a lot of extra code perhaps to do the UI like the high-level routines do.

These routines let you, for example, search for multiple items or manage Keychains themselves as opposed to the items in the Keychain. And the last area of the API is the whole area of notification. So when something happens with a Keychain, when a Keychain locks or unlocks or when somebody takes data out, you can get notified when those things occur. And then the last thing I'll talk about there is the new factoring of the API between Carbon and core services.

And then once you've figured out that the Keychain Manager is available, you can either find or add a password. The first thing you'll do is try to find a password in the Keychain. And there are three high-level calls in the Keychain API and Carbon that let you do that, depending on the type of password you're looking for.

So, for example, if you are that FTP application, you can call find_internet_password, pass it the attributes you're looking for, the name of the server, the fact that this is a password for FTP, and those sorts of attributes. And then it'll return the password if it's in fact found in the Keychain.

And the flip side of that is adding an item. If the item wasn't already there, perhaps you want to store it in the Keychain. And there's three calls to do that, depending on the type of password that you want to add. Again, all of these are in Carbon. And because they're high-level calls, all of the sort of housekeeping tasks of making sure the Keychain is unlocked, creating a Keychain if necessary, is all taken care of for you.

So, as I said, the high-level APIs sort of encompass or encapsulate a whole set of low-level calls and just makes it convenient and easy to use for you. But the low-level calls are there if you need the flexibility. So, in this case, the Add Internet Password call is really just a wrapper around a whole series of the lower-level calls. The first to create a new item and then to add it to a particular keychain.

And then we make a series of calls to set whatever attributes we need to set on the item. And then finally, we need to set the data of the item, the thing that's important to protect. And the last call there is Update Item, which writes it out to the keychain.

So here's that diagram again, and here are the two sort of components of the Keychain API. If you're a Carbon application, everything is there available to you from Carbon. If you are not wanting to use Carbon or you are, for example, a Unix command line tool, you can call directly to the Security Core APIs.

Again, the split is sort of along the lines of does this call require UI? So, the high level calls in Carbon, may display user interface. For example, if the key chain is locked and you make this call to find the password and a password is found, the user may see a dialogue box come up asking to unlock the key chain.

And that's the sort of call where these things happen in line and UI could come up. So, they remain in Carbon. When you're a Carbon application using those, it automatically pulls in all of the lower level APIs that are in Core Services. So, everything there is available in Carbon.

If you are going straight to Core Services, if you're going straight to that level, those API calls do not display UI. And in order to use them, you'll include CoreServices.h. And again, this is something that can be used by any application, but especially applications that don't want or need to rely on Carbon.

So, the basic API routines at that layer, like I said, give you a lot of flexibility. If you want to just create a new item without adding it to a particular Keychain, you'll use new item. Add item, of course, adds an item to a particular Keychain. Always you're going to access an item through a reference called a KC Item Ref.

And no matter what the item is, they're all treated the same. You'll always use a reference because you don't know exactly what the composition or the backing store or any of that needs to be. If your application uses item refs, it doesn't have to worry about any of those underlying details. You'll use get attribute when you need to get an attribute from an item and set attribute will, of course, set the attribute on the item. And the same thing with data. Get data will get the data of the item and set data will set it.

When you're all done sort of, you know, adding or, you know, changing the item around, you'll use Update Item, which will write it out to the Keychain and commit it. And when you're all done with an item, we want you to call KC Release Item because that will release the memory that the item occupies.

Again, if you need the flexibility of being able to find more than one item in a Keychain, we provide sort of a lightweight database-type API called FindFirst and FindNextItem. FindFirstItem, of course, you pass in the same sort of thing that you would to the higher-level ones in terms of attributes. These are the things I'm looking for. Find these items.

And what that will call, what it will do is return a search reference. And then you can pass that search reference to FindNextItem and continue searching until no more items match. And when you're all done with one of those multiple item searches, you can call KC ReleaseSearch and that will release the memory that it occupies.

Now, in a similar way to using a KC Item Ref when you're dealing with items, you want to use something called a KC Ref to refer to keychains themselves. Most of the time, your application won't care about keychains or where a particular item is stored. But if you do, you'll use a KC Ref. We provide two routines there to sort of translate between a KC Ref and an object in a file system that's specified by an alias record.

But it's real important to realize that it's not always going to be a file. And in fact, you really can't assume ever that a keychain is a file on the disk. That's a bad thing to do. If you were at this talk last year, I said the same thing and it's still true.

Now that we have actual keychain access, we can't assume that a keychain is a file on the disk. So, we're going to use a KC Ref to refer to keychains. Ken McLeod Now, in a similar way to using a KC Item Ref, we provide two routines there to sort of translate between a KC Ref and an object in a file system that's specified by an alias record. But it's real important to realize that it's not always going to be a file. Now that we have actual smart card support in OS X, this is going to be coming sooner rather than later.

So, it's real important to remember that. KC Get Status is a routine that's your friend. It will tell you a lot of information. It will tell you whether the keychain is unlocked, a particular keychain or the default keychain. And it will tell you whether the keychain can be written to or if it's just open read only. And Get Keychain Name is pretty aptly named. pretty aptly named, it will tell you the name of the keychain.

If you need to explicitly unlock a Keychain, you have KC Unlock Keychain. Again, most of the time, you won't need to worry about whether the Keychain is locked or unlocked because all of that will be taken care of for you and will just prompt the user to unlock the Keychain if it's necessary. If you need to create a new Keychain, you'll use KC Create Keychain. And if you need to look through all the Keychains that are available in the system, we have Count Keychains and Get End Keychain or Get a Keychain at a Particular Index.

The notification section of the API is pretty useful. Every time an event happens with a key chain, someone unlocks it, someone locks it, someone adds something to it, someone retrieves data from it. This generates a key chain event and your application can register to get these events to sort of see what's going on.

Perhaps you want to write a logging application that logs all accesses to the key chain. You can do that by registering for key chain events. You'll call add callback and that will register a routine that will call to let you know when these things occur. It will give you information about what key chain it was, what key chain item it was, what the process was that asked and so on.

You can register only for those events that you care about. For example, you may not care when the key chain locks or unlocks. The only thing you care about is somebody retrieved data. So you can just register, for example, for that event. . . . . . . . . And when you're all done, you can call Remove Callback before your application is ready to quit.

Here's a little snippet of code that shows how simple this is really to use. This routine, connect to server, takes two arguments. We're about to connect to a server and we know something. We know the server's name that we're going to connect to and we know an account that we want to connect as.

So the first thing is to see if there's a password in the Keychain before we go and ask the user to type in their password. So in this case, KC Find Internet Password takes a series of arguments. And the first argument it takes is the name of the server.

And so I can just pass that in. The server in this case that I'm interested in. It takes a security domain argument, which is a string. In this case, I'm not concerned about the domain, so I pass nil. I pass in my account name. I can pass in a port.

Since I'm not concerned about a particular port, I can pass the constant anyport. I can pass in my account name. I can pass in a port. Since I'm not concerned about a particular port, I can pass the constant anyport. I can pass in my account name. I can pass in a port. Since I'm not concerned about a particular port, I can pass the constant anyport. I can pass in a particular protocol type that I'm interested in finding and an authorization type. Or I'm sorry, an authentication type constant there.

And then I pass in a buffer, a pointer to a buffer that I provide, and the length of that buffer. If this call is successful and it actually does find a password, it will fill in the buffer with the password and return no error. So after I've made this call, a number of things could have happened. It could have gone off, asked the user to unlock the keychain, created a keychain if no keychain existed.

All that stuff I don't have to worry about in this routine. It's all sort of handled for me. So down there at the bottom, if there's an error returned from this routine, then I know that no password in fact was there in the keychain. And I'll need to do something to ask the user for the password as I normally would. And I call a routine there, my get password.

And I call the user's internet password, which actually would go off, assuming that it got the password from the user, could go off and call kc add internet password to put it there in the keychain so it's there for next time. And then when I get to the very bottom of the routine, either way, I have a password and then I can connect to the server.

So the nuts and bolts of what your application needs to do to use the Keychain. If you are a CFM application that's going to be running on 10 and 9, you'll want to link against CarbonLib 1.1 or greater, which has the Keychain API in it. If you're a Carbon application on 10, of course, you will link with the Carbon framework.

And if you are a Cocoa application, you can link with either one, depending on what your needs are and which portions of the API you want to bring in. If you are a command line tool, you probably should not link against Carbon. You'll only want to link with the core services framework and the things that don't necessarily require UI.

The Mac OS Keychain is a tool that is run into is an application that's perhaps a command line tool, something running over, you know, you're logged in via SSH, let's say, and you're running this application and, you know, you can't put up UI. You have a command line interface.

So, If you have no way of unlocking the Keychain via this dialog box, we provide the ability to unlock it programmatically with KC Unlock, but again, this is something where UI is not the way you want to go there. The second point that I wanted to make is that when you're using the Keychain, you should always let the user decide to use the Keychain and let the user make the decisions about when to interact with it.

The way a lot of apps handle this is when you have a password dialog box, it'll have a little checkbox next to it that says, "Add this to my Keychain," or maybe, "Remember this password." Again, you're letting the user make the decision at that point. whether or not they want to store it.

And the final item there is a real fundamental principle of UI design that often gets lost, but it bears repeating. And that is, All of the things that occur that bring up UI should be the direct result of the user having done something. So if I make a call to find Internet password and it needs to put up a dialogue, that's the same as my directly putting up that dialogue. And if that occurs at some point long after the user has interacted with your application, it can be very confusing.

If I set up, for example, a mail account and then, you know, 30 minutes into the future, mail is asking me for my Keychain password or permission to access it, there's no consistent sort of connection in my mind between my act of, you know, interacting with the mail client or whatever it happens to be and its use of the password. So when you call KC Find Internet Password or any of these high-level APIs that can bring up the data, be sure that you do it as a result of something the user has done. They've clicked Add, they've clicked, you know, Connect, whatever it happens to be.

So, along those lines, it's entirely appropriate to cache items that you retrieve out of a Keychain. Especially on 10, when you have a protected memory model, you can hold something in your own process's memory space and other processes running on the system, the user happens to start up, can't get access to it. The caveat there is that while memory is protected, you want to protect against that thing getting written out to disk.

And the way to do that is to lock the memory. You always make sure that memory is locked if it contains sensitive data. On Carbon, the calls that you'll use to do that are hold memory to actually lock it down and unhold memory when you're done with it. And the same thing for, if you're using BSD at that level, you'll use M-lock and M-unlock, which is essentially the same thing. So now I'd like to actually show you a demo of how this works on OS X.

Down here in the Applications and Utilities folder is your friend, Keychain Access. This little utility will show you your keychains and let you manage them. It shows you what's in a keychain. In this case, I have a keychain that's empty. So, start off with nothing in my keychain. And I'll set up a mail account in the mail application.

actually have an account set up here. I have a particular email address and I have a server name that I'm going to be connecting to to retrieve mail and a username. Now it makes logical sense that those are good attributes for a keychain item. If I'm storing a password in the keychain, those are tags that I can add as attributes so that I can find that particular password when I go to connect to this server.

I'm not going to type in a password For now, I will... "I'm going to actually get mail at this point, and when I click that, I guess, uh, Here, let's quit and try again. I think what Mail did was cache my password from when I set this up.

So, when mail actually goes to connect to the server, it has looked in the Keychain, found nothing there, and is putting up a dialog asking me to type in my password. So I'll go ahead and do that. And then I can make the decision to actually remember that or store it in the Keychain.

And then I go off and it goes off to the server and looks for my mail. Now notice what happened in the Keychain. An item just got added. So, let's quit mail and take a look at this item. It's got a label here, which is the server that I connected to. It put an internet password in there with the account name that I logged in as.

Now there's something new for OS X with Keychain items and we have an access control pane now in Keychain access that lets you sort of set up who has access to this particular password. So by default, the mail application created it and we give mail access by default to this item.

You can turn off access altogether or you can allow access by any application that wants to access it without putting up that warning dialogue. So to show you what that looks like, I'm going to actually remove mail from that access control list. And now mail no longer has pre-approved access to this item. So when I go to save this list, I get asked permission to actually change the access control list here, which I will do. And I'll go back and run mail.

Mail goes off, tries to look the password up in the Keychain, finds the password, but it doesn't have access to just get the password without the user's knowledge. So I get this confirmation dialogue. And I can look at, in fact, the details of this. This is the Keychain that is being accessed and this is the particular process that is wanting access to this item.

And my choices are I can allow this to occur just once or I can permanently allow it to occur by clicking Always Allow. And when I do that, if we go back to the access control pane of this item, we'll see that mail's been re-added to the list.

So Mail is one client of the Keychain in OS X, but it's integrated pretty well throughout. The Finder has a connect to server to connect to a particular Apple share, I can speak, Apple share server. In this case, I can connect to iDisk.mac.com, which is really just an AFP server.

So when I go to connect to it, It asked me for a name and password. And again, Apple Share has provided some human interface to let me decide whether or not I want to store it in the Keychain. So I'll click yes. I'll go ahead and log in as the account that I set up.

And I can mount that volume. Now, I talked a little bit earlier on about providing a transparent authentication experience. So, one thing I can do in the Apple share case is to make an alias of the server, or I'm sorry, of the volume, and then I'll go ahead and unmount this volume.

And let's first examine this item and see who has access to it. So we see that the finder has access to it. So now if I go back to the finder and I double click on this alias, because the finder has access, - You get the spinning cursor and the volume just mounts without having to type in a password.

The other thing that's new in OS X with Keychain access is the ability for users to add their own types of passwords. For example, software registration numbers, credit card numbers, PIN numbers, whatever it may be. All they have to do is click "Add" and I can add something like, you know, my software serial number.

For me, and I'll type in whatever that happens to be. I can look at it in clear text if I want to. That's not what it defaults to. I'll go ahead and add it. And now I have an item that I stored without a whole lot of musts or fuss. I can give a applications pre-approval to access this item. If I know that a particular application is going to need this password or this serial number, I can go ahead from this interface and change the access control list.

I can go to For example, applications and, you know, maybe it's a serial number for a chess game. So I can add that and now whenever chess looks for a serial number that's stored in the Keychain, the user won't be bothered with the dialog asking for permission because chess is pre-approved.

Now, I mentioned that by default, the Keychain is unlocked when you log in and it's locked when you log out. You can change those settings at any time. You can have it lock after a period of inactivity or when the system sleeps. And of course, at any time, you can manually lock the Keychain.

So if I manually lock the Keychain, Then those things that need to access it will require the Keychain to be unlocked first. So when I double clicked on that alias and the finder, or in this case Apple Share, did a find to look for its password in the Keychain, the Keychain was locked. And so we take care of putting up this unlock dialog for you and your application just doesn't have to handle all of that. So I'll unlock the key chain. I did enter the wrong passphrase.

And then when the Keychain unlocks, the volume will mount. So that's pretty much it for the demo. Go back to the last slide if we could. So just to sum up, the Keychain is like a bank vault for all of your sensitive passwords, keys, things that you need to store securely. And it's provided for you as a system service, so it's always there and you don't have to roll your own code to do the encryption. It's very simple to use. Most applications just need to do find and add.

And All of this is there now in OS X as shipped out of the box. So go ahead, get started with it, and thank you. What I'd like...

We have a number of security sessions here. Of course, now three of them are already over, but encourage you to look at the session on Kerberos. And if you can, if you happen to miss any of the other two, try to take a look at those when the sessions become available in whatever format they become available in.

And then please come on Friday and talk to us. Tell us what you want to see, or if you have concerns about this or suggestions for how we can improve it. Please let us know. Here's the email address for all of your questions. Talk to Craig. Craig makes sure that we, or the appropriate team, gets notified so that we can handle whatever issues come up.