Welcome To Integrating Smart Cards in Leopard. I'm Shawn Geddis, Security Consulting Engineer in the Enterprise division of Apple. So again, welcome. We want to take you through a little bit here somewhere. On introduction to smart cards here. It would be interesting to figure out how many of you are already using smart cards, how many of you are deploying, how many of you are in the information gathering stage. Hopefully there's a little bit of all those. Maybe even some of the developers deploying some new integration with their products.

So in this session what we want to do is introduce you to smart cards as a secure and reliable source of identification. We'll talk a little bit more about that but, that's really been kind of a key drive of folks within the enterprise space. A key need, I should say.

We want to talk you through some of the enhancements we specifically did in Leopard for the smart card services. And most of all we want to spend a little bit of time in one of the key new services, one of the key new features of integration with smart cards. And that is in the unlocking and giving you access to File Vault encrypted storage.

So hopefully out of this you're going to learn how those services are tied in with Tiger. How we've been providing those services throughout the 10.4 train. Again, some of the very specify enhancements that you may be able to leverage once you get Leopard out there, you may be able to look into your developer that you have today. And finally what steps that you need to take and that you can take with integrating that right into unlocking File Vault and even into unlocking of keychains.

So first of all any time we have these kinds of discussions let's first of all try to be sure that we are all in agreement on what it is we're trying to solve. A lot of us engineering, we come up with a solution and potentially we don't have a problem that we're trying to solve. In this case, the problems, the IT organizations, you yourself, many of you may actually be some of the customers I have dealt with in the past -- are trying to solve several problems.

One is, again, providing that secure and reliable form of identification. Again, why do we say that? It's something that's a known entity. We're talking about the smart card. So there's protection on that for protecting that identity. Many of you are facing organization that may actually be a sector that's mandating the use of these devices.

And moving a little bit closer to giving that user experience of a single sign on. Many of us have various credentials of getting access to services on back-end servers on our local work stations, lap tops, and we're just inundated with various authentication methods over and over and over again. So the second one there is the single sign on experience. Driving that with a strong form of identification, that smart card, and maintaining that as our single form of identification for a single sign on.

To kind of round this out, this also ties it into really kind of the data integrity, making sure that things haven't changed. The confidentiality. Protecting your data, making sure that only the right people see that information. Again, these are key problems that you as IT, as IT staff are trying to address. And finally, why you have all these mechanisms and solutions in place you can then ensure and prove -- what's referred to as non repudiation. Making sure that individual that did the translation is indeed that individual, or the individual -- that proper credential smart card.

So now that we know what we're trying to solve, let's move forward with what Apple has been providing in 10.4 to help you address some of those needs. So in 10.4, if some of you were here last year at WWDC, we started giving a little bit of insight into those services.

And built into 10.4, smart cards are integrated into the authentication mechanism for log in, system administration, unlocking of your screen saver obviously for the user. Secure web access for VP N or remote access. And then finally for S mime. So those are the services that we want to kind of look through real quickly to kind of highlight what Apple's provided in 10.4 and then move on from there.

So as I mentioned here earlier in kind of my introduction, one of the key things that we're also going to be pulling out is the new feature of tying that smart card in to File Vault. Many of you may have been aware or trying to figure out how in the world to use it with File Vault in 10.4. And that wasn't there until -- now with 10.5.

The other thing to keep in mind here when you're thinking of smart cards. When you're comparing OS X to other platforms, one of the key differences here is that Apple has abstracted those cards, the smart cards themselves into the whole keychain credential environment. Right? Other platforms, whether you're a developer or you're doing some system administration. You had to deal directly with applications interfacing directly with that card. In OS X, the smart cards themselves are abstracted into the OS as just yet another keychain. There are some nuances about it, but they are just another keychain within the OS.

That's a thing to keep in mind as we go forward. Let's go down to the card. Let's be sure what they're all on the same page, physically, what is on these cards and what you use. A typical -- and I say typical -- PKI based smart card. This is cards that are used for -- use of, again, S/MIME.

Secure web access. Those kinds of services. Is -- frequent profile so to speak is the use of three unique identities here. An identity being the certificate of the private key. The first one being the user's identity. The second one being associated with e-mail signing. And a third being for encryption.

Did I mention about kind of a typical card. The profiles or the objects that are on these cards differ greatly. And there are smart card efforts around the world. If you look at each one of those they're significantly different both in the objects themselves and the keys that are available in each one of those certificates. But keep in mind what a typical card is like.

So I mentioned about the various services. So let's look at each one of the those and quickly kind of grasp how the services are integrated in 10.4 again First of all we talked about secure, form of authentication. So now we're actually doing authentication at log in. So we're providing two factor authentication. For those of you who are unfamiliar, two-factor is where you have something in your hand, something you have, and then something that you know. It's that pin on the card. So you're unlocking access to your account at log in.

Associated with that, the key aspect of OS X that you need to keep in mind when you're thinking of authentication is the corresponding authorization. Right. Because I may be an administrator, I am not always authorized to do all activities on my machine, on an end user's machine, or maybe even a corporate server.

So to keep us all on the same page here with the authorization, let's run through this. We're talking about the acquisition of a right in order to be able to perform a task. And the corresponding rules associated with that. Think here that the application up in the upper left-hand corner in the log in window. That then would be one of those services requesting authorization.

That log in window is then requesting the right for that user to log into the security server. The security server then parses some information from the authorization database. And if you physically look on your machine in etc authorization, it's an XML flat file. That defines the rights and the rules that we're speaking about here. Interrogates that, gathers the information. And now learns has required by that user to authenticate and prove who they are to acquire this authorization right.

In this case, the request is being handled by the security agent. So this is out of band in the application. This is where the applications don't really do direct inaction with the validation of this user or with the associated rights all handled within OS X itself. So the user may be requested to use a smart card, may be biometric related. Maybe some other form much identification.

Once that information has been acquired out of band, comes back through, handled by security server, an then the appropriate right is then granted to the security server. In this case, the log in window. So I would successfully log in with a smart card. Keep that in mind about how we deal with the rights going forward.

Let's look a little bit closer now at what you probably have faced and what you may want to even change going forward associated with the rights and the rules in etc authorization. I just mentioned about log in -- if you look in Nets authorization, the right system dot log in dot console, is the right that is required for any user to log into OS X. Okay. And this is kind of the beginning part of that right, etc authorization.

And you'll see that this is the much longer contents of that right where you see the gold lettering and the red lettering. This is where many of you probably have either manually or -- leveraged some scripts or some diff files that we've provided some folks off line. You removed the off internal and added the two lines that were built in for smart card. So in 10.4 you had to manually modify the authorization to allow log in, in OS X. It was -- the services are there, but it wasn't out of the box ready to go for smart card log in.

You had to make these modifications to enable that capability. Well, the nice thing is in 10.5 all of that's done for you. So all of the modifications you have to do on 10.4 systems are all handled for you already in 10.5. So let's look at the corresponding rule with logging in. And this one is for authenticate.

Now again, the same additions and sub traditions of line into that rule and you'll see within this mechanism with the removal of off internal and the addition of the two built in references to smart card. These are references to off plug-ins. So if you're wanting to add some additional authentication mechanisms you do this through the addition of off plug-ins. Okay, again.

Same thing with the write. This rule is already handled directly from -- within OS X 5, within Leopard. Okay. So we did a little bit of under the hood looking. The next big issue that you're facing is how do I integrate these smart cards into my directory services.

How do I make sure that my user authenticates to Open Directory, or maybe to even Local Net Info, or LDAP or maybe Active Directory. What Apple provided was two methods to give you the ability of leveraging your infrastructure for user authentication of the smart card. This two factor authentication.

The two methods can be references. A cryptographic data exchange, it's really kind of a reference to how things are handled with the keys. And then the attribute matching. Kind of a reference point of information that comes from certificates in matching that value with your directory service. So let's look at each one of those real quickly, give you an idea of how it fits and whether it does fit in your environment. Some folks will need to leverage one method and wouldn't be able to leverage another depending on their service implemented.

A typical approach here and a better approach is the initial method I mentioned, the cryptographic data exchange. And this leverages the use of the Public Key Hash. So when you're thinking what on that card. We went back and saw the identity being that certificate and key. Really what you see here at the third bullet there, it talks about locating the Public Key Hash.

Once you set up a card using the cryptographic data exchange, if you look at the authentication attribute in your user account you actually see the addition of Pub Key Hash and this really long text value. Right? This is the value -- this Public Key Hash associated with which identity you're going to use on that card for the authentication of the user.

In this method it also doesn't matter which one you pick from your card. Right. There are several folks that want to use certain identity, certain -- remember you go back to that typical card where you had an identity, e-mail signing in and encryption. It doesn't matter which one you use for this with this method, crypt graphic data exchange.

The other method which is probably more prevalent to many of you, is the need to map between a -- an attribute on the card and an attribute in the user's record in your directory's service. And what's typical in many environments that we've dealt with, with our customers, is they're drawing from an attribute called the NT Principal Name in the e-mail signing insert on the card, and mapping that to the User Principal Name in active directly Okay. That would be the typical mapping that a lot of folks that we have dealt with have used.

So that method would give you the ability of back end management. Adding that value to the User Principal Name, and allowing that user to go between machines and authenticate again to your directory service. In this case, maybe Active Directory. So let's move a little bit forward a little bit faster through some of these services. To just better explain again how the smart card services map in here.

If you're doing system administration, we talked about System Preferences when you're doing the unlock. Rather than the user name and the password you now have the ability for the smart cards. One thing I haven't mentioned yet is that with the smart card services it gives you the ability to use both your user name and password for the use of a smart card if you've inserted your card. So if you look here and getting ready to modify the System Preferences, so it's asking me for a password.

If I insert the smart card, what ends up happening is that password switches to a PIN, because now it's recognizing the card is associated with my account. I am now asked for the PIN to unlock access to the private key on that card. Again, there's some references to the available rights and related preferences.

So now let's move to another area. You're providing secure web access. We're talking about some of the new web services that you all might be developing, might be deploying in your IT infrastructure. How do you get the smart card services leverage in your environment? So when you're doing web access, what you're wanting to do is provide user authentication to that back end service.

And the one thing that I want to be sure that many of you understand is that Apple's approach to providing user authentication and we'll talk a little bit more this afternoon about PKI and certificate management, is to provide as much kind of zero configuration approach as possible. So let's think about that thought as we move forward with leveraging identities with these cards. So let's say I'm trying to access my SSL VPN with my smart card. I am going to attempt to access the service. But what's happening under the hood here with my smart card.

Well, first of all I get a little challenge going on with the server, and it's requesting proof of who I am. So I have to present my identity. In this case, it's leveraging my identity for my card. So I have to enter my PIN, unlock access to the private key. I do my exchange with the server. If everything's okay with my -- and my validation on my server side, everything's good to go. I'm trusted; I'm into my service.

Now if I do that same thing with multiple identities, now that becomes a little bit trickier if you're trying to drive a zero configuration environment. How does Apple handlef this? Okay. You kind of walk through the same steps. I'm challenged from the server. Try to do the standard exchange.

I get challenged with my PIN from my card. I unlock access to that. And I'm really sending off the first valid certificate out of there. Well, what ends up happening is its potential that the back end service wanted a different identity, a different certificate, from my card than what was initially sent.

In this case, it would be rejected at the server and now I would need to maintain some reference to the one that I selected, what should be used at this site, so next time I go there I don't have to keep selecting that every time. Okay. So zero configuration as best is possible. And any time you have a variance in that environment where you have multiple identities I should only have to select once and retain that point, that reference that I have my personal preference.

So let's kind of walk through this visually. I am going to this web site, and it all -- proper exchange takes place. But my first certificate that was sent to the server isn't accepted. What ends up happening is Safari displays all the variable additional certificates that I can select from that could potentially be sent as well.

Again, this is a case where I think I had, like, about half a dozen identities, certificates, here that I could send. So Safari's going to display which ones that I could use, have proper key usage. I would then select that, and the system would retain that reference going forward. The thing to keep in mind here is that the reason Safari displayed that list is that the remote service rejected things at the protocol level.

What I mean by that is that we've seen several folks have some infrastructure where if the user does not successfully authenticate -- in this case with certificates -- that what happens is a -- in some cases a web page gets sent back to the user. So you have this catch 22.

Right. Your services are sending back a web page telling the user, well, you need to select a different identity; certificate. But the user can't select one because you didn't actually fail the protocol. We've actually addressed this in some new features in Leopard to help you with this situation. If the server doesn't handle this as expected at the protocol level.

I keep referring to this retention as identity preference. What actually happens now and has been happening in 10.4 if this was in your environment. Once you select from that list, right, of potential alternate certificates, is this identity preference is added to your keychain. It's that hint for that personal preference that is there so that next time a service like Safari goes to hit that particular URL I no longer get prompted for which one I should select.

What happens now is the request for that URL Safari is actually at lower levels of frameworks is actually looking for if there isn't a preference for that site. In this case, I already set it that one time. I will never have to set it again unless things change with my identity or with the site.

Some new stuff in Leopard here that we're going to go into a little bit more is this actually gives you the ability now of selecting a different certificate manually within keychain access, as well as even changing the URL that you're wanting to go to. And we'll talk about giving the ability of manually setting something in advance so that users don't even have to respond to that list.

So if you look in Keychain Access in Leopard, and this should be in the builds that you all have. If you select in the categories field -- and I want to explain this a little bit because people are confused -- if you select in that category list in Key Chain Access where it says My Certificates, that My Certificates really refers to your identities. Right? The certificates that you retain the associated private key.

Okay. If you select the one that's above it that just says Certificates, you're just going to see the certificates in that keychain. But if I select My Certificates, I'm seeing those searched that I have the corresponding key for. And I think I have it in different set of slides here. But visually in Leopard as well, you see the disclosure triangle right in front of it. You would actually see that association, which wasn't there back in 10.4.

So now there's this contextual menu ability in Leopard where I can now bring up, and you can see the top option is New Identity Preference. Right? The ability to now manually select this. As I walk through I can now manually enter the URL and also note there it talks about an e-mail address. Right? We're going to get into that in the e-mail side. This gives you the ability of manually setting an identity preference for both the URL and for e-mail addresses.

In this case, going to your SSL VPN. And again, same thing. Once you've set that it's put into your keychain, access list here, into a particular keychain that I had in this case for that particular site. Let me move a little bit quicker through some of these services. Hopefully you're aware of the fact that Internet Connect has the capabilities of relying on certificates -- smart card based or keychain based -- for the VPN Solutions Layer 2, Point to Point, and also 802 dot 1 access control.

Okay. So those are other remote services that have full access to the smart cards. And I'll go through these quickly. Layer 2, if you select user Authentication For Certificate what you'll see is that quick dialogue on the right side that says select certificate. You select what whichever server is available for that key usage.

Same thing with Point to Point in selecting certificate for that user authentication. This is really where you're doing EAP-TLS. So you're doing the -- the validation of that user with a certificate. And again, with 802 dot 1 A. Very simple interface for users to set these configurations up if they want to do it manually. So let's quickly jump to mail.

Secure e-mail with smart cards. So S/MIME. And again, remember, I talked about zero configuration. So how does this work. Several folks have talked to me in the last couple years and kept saying how in the world do I con figure mail to work with a smart card. How do I configure it to use my identity that I just acquired from some CA.

Well, in this case, again, this is a perfect example of that zero configuration. There's nothing that I do within the mail app to configure it specifically for the use of smart cards except for a point I will bring out that's just more of a careful entry of information.

So you'll see I'm composing a new message, and you'll see the little certificate reference, kind of a signing reference, a little check there. And then the lock reference to encryption there on the right side of the Compose window. So where does that come from? Well, when I go to compose that message, Mail is actually requesting from the OS, is there an appropriate e-mail signing certificate somewhere in this user's credential store in one of the keychains that would be valid for the e-mail address that I'm sending from.

I point to the e-mail address because many folks have gotten caught on this, and that's where I just want to bring that to your attention. The -- when you're dealing with the RFCs here with the S/MIME you have to be careful because everything to the left of the At symbol is case sensitive.

Okay? So within Mail I had configured my account to be capital G and lower case e-d-d-i-s -- it would not have given me the option of actually signing this message. So it's really not a special configuration on my account, but just careful that the case sensitivity of my address in my mailer, my mail app, is identical to what's in my certificate.

So the same thing moving on with somebody I'm sending to, I am going to encrypt a message to Joe user. As long as my system has the available access to a public certificate I will be able to do the encryption directly to this user. And there's a session later on today that we get into much more of this.

So many of you have asked about adding your own smart cards, adding a new card type. And wanting to know what Apple supports out of the box. What we've done is shipped an environment, we refer to it as Token D, to support the actual card interface. This gets a little bit lower.

So if you're the IT folks that don't care about this, this is when you kind of zone out a little bit and catch up on your notes. But for the developers and the low-level people, key into here, because this helps you understand what cards are supported and what aren't.

Out of the box shipped in OS X we provide Token D interaction. Token D is here to support three major smart card initiatives around the world. Jack being a reference to the Department of Defense within the U.S. government, Belpic, Belgian, and JPKI is Japanese PKI cards. Well, new in 10.5 there's a new standard within the U.S., again, given by the U.S. government -- outside just of the original DOD CAC Specification or PIV -- or Personal Identity Verification. That is actually coming -- that support for PIV is coming in Leopard. So if you need support for a PIV card within your application, once you have Leopard you now have access to that card.

Okay. So here's -- we go just one level deeper for those of you that need to know this information. Green is the applications. That's Mail, that's Safari, that's log in, it's anything up here, if you need this information. Applications are requesting access to the services, these objects, through the security APIs, which are all on top of CDSA.

So what happens underneath the hood here is when you attach a reader to your system, Security D actually now launches and manages PCSCD. So if you're a developer and you couldn't figure out why in the world PCSCD wasn't running when your system was running, launched or booted up. The reason is we launch these services only when they're really needed.

Right? To keep kind of a low footprint on that. So if I attach a reader, system launches PC S CD to do that communication. Once you stick in a card I will show you a real quick demo in a little bit. The appropriate Token Ds, they're all launched, and it attempts to probe the cards to determine what card type that is.

And one of them wins. And we'll see that a little bit later. So that's kind of a low-level. Each one of these are Token Ds. Right? Each one of those card types that we mentioned here. And you'll see a module in System Library Security Token D on your system for support of each one of those cards.

I think I mentioned most of this. Again, it's one token for each card. And your smart cards really now appear at the top of your keychain list. So when identities or certificates are searched they're really the first ones that are searched. So we're talking about all the cards. But there really is the challenge of now that I have a card, how do I get access to it on my machine.

Okay? Of the most predominant and desk approach is what's referred to as CCID. And Apple's provided a CCID class driver in the OS. So if you acquire any CCID-compliant reader, it should just work. No additional drivers needed. It should just work. Microsoft has done some provision on CCID on Windows's side as well. So many of you if you're buying readers, now a days many of them are.

There are some proprietary ones. But if you have a CCID class drive yes, sir, a CCID-compliant reader, that's the best thing to go with. It's just going to work. What Apple did to extend that a little bit more is include some key driver support for many of the readers that were used across some of those larger smart card projects around the world. Again, from some of the major smart card reader vendors.

And of course, if you're getting into some development and you haven't done this before and you kind of need some open source stuff to draw from in addition to ours, looking at the muscle site for some of the drivers is a great place to start. Again, the key is if you go with a CCID compliant reader you're done; done deal. So now let's take a quick look -- I just wanted to show you a little bit under the hood of what I've been mentioning about those services. So let's switch over to the demo B system.

And what I wanted to do is again, give you a couple quick methods. Maybe just some steps that you can use to identify if things are working properly, or where you may have some problems within OS X. So I've got a smart card reader attached to this system. What I have up here is Keychain Access. Again, that's the way that you're visually seeing keychains, since we abstract smart cards as keychains now, this is where you're going to see them.

What I also have up is Terminal. And the reason I have Terminal up is to give -- let me do a little bit of window management here -- the reason I have Terminal up is to give you a good idea of what's going on underneath the hood. And the easiest way to do this is just run the top command here to show what's running on that machine. So what I want to do is insert one of those cards. This one being one of the common access cards.

You'll see there within a Terminal window a whole bunch of different processes starting due to timing and the refresh. You're not going to see all of them sometimes. But what you do see now is that the top process is CAC. Remember, I mentioned that's one of the Token Ds that we have in the system.

So I know have a unique process running associated with that card. And if I go over here to Keychain Access, I look right in the keychain list. Now I see a new dynamic keychain that's added to my list that refers to the card that I just inserted. What's happening is it's doing some interrogation on that card, determining the objects on there. And you now see a reference to that card, the search and the private keys. Right? We all know that private keys, I can't pull those private keys off the card. So this is really a reference to those objects on the card. An abstraction into the keychain environment.

Now one of the unique things to 10.5 to Leopard is that there is some built in UI within Keychain Access. So if I am physically looking at my keychain list, upper left-hand corner, and I now double-click on that keychain, what will happen is its prompting me for the PIN, essentially protected data on that card.

Okay. What will now bring up is this new UI that we're providing in Leopard to now see all the information that's in addition who that card that's not a standard kind of PKI. It's not a standard certificate on a private key. Just gives some flexibility in viewing PIN-protected data on that card that I might not see in kind of a standard keychain list to the right here, again, with the certificates and keys. So in this case, this is the common access card. Those of you familiar, this is the same information that you saw using previously we provided this as CAC viewer. Common Access Card Viewer Utility. All of that functionality is now moved into a plug-in into Keychain Access.

Okay? One other as sect I want to bring out here, then I need to turn things over to my -- my colleague here -- is associated with Keychain Access, if you look at the preferences there's some key points that you need to be aware of and that you need to look into a little bit more. First of all identified mentioned about the certificate and PKI management session later on today. That's a session where we're going to take this much further.

But many of you are needing to look for certificates for the users you're sending, let's say, an encrypted message to. Without having those certificates locally stored, you need to pull them from a server. LDAP accessible server. That's really where you're selecting in the preferences the ability to do that, physically here for searching directories.

The other thing relates to the handling of the validation of that server. Right? The revocation. The two areas or the two methods of that are OCSP and CRL. All those are built in services in OS X. By default they're both turned off. So again, if you're wanting to choose which method you're using, if your card supports both, you could manually select or now with OS X, you're going to hear about newer ways to set some of these from a command line as well. But I could set, in this case, the best attempt. My system would go out and do some validation of those certificates and provide that functionality up to my application. Whether it's mail app, again, web access, those kinds of things.

So this is kind of a -- just a quick run through of some of those tools and access to the cards. And you notice there, as soon as I yank my card, it now no longer is a keychain that's available to my system. Okay. Some really quick understanding of what's under the hood. So let me now make my way back and we'll go back to slides.

So let me bring John Hurley up. Security policy architect at Apple who's done some of the major work related to tying smart card authentication into unlocking of File Vault itself.

Thanks Shawn. Okay. So we'll go through a couple. New features that we've added into Leopard that I think you'll be very happy to see. It's possible to do some of this stuff by kind of monkeying around with disk images and whatever on 10.4. But now it's actually integrated in.

So on 10.4, you know, on the Tiger release, we did have File Vault. And this is an encrypted container for a user's home directory. And it's really ideal for portable computers, anybody travelling. It's a very, very easy way for user to key their data safe without really having to think about it. They don't -- they enter their PIN, they log in, and hey, all their stuff is there. And they don't really care that that's encrypted. But you guys do, because you're responsible for protecting their data.

So currently the way it works on 10.4 you are going through the log in process, and as a side effect, the user's password is passed off to unlock this disk image. All these File Vault images are actually disc image, file on disc that you could create manually with the Disk Utility even -- a key is generated from the user's password using an algorithm called PBKDF-5.

And it kind of mushing around the password, the user's password, and turns that into a cryptographic key that it can then use to unwrap the data that's on the -- that's in the File Vault. One thing to note about that is of course you should have your users pick a strong password.

Obviously, if you only pick, you know, a short password, that's only going to have certain number of bits of entropy, and it won't act -- successfully protect your File Vault. But there are -- if you hunt around in here and Keychain Access -- actually, anywhere you're creating a password, you can use the password assistant and come up with, you know, some pretty easy to remember passwords. So that's just a side note.

On 10.4, the -- the key that's protecting the data is an AES 128-bit symmetric( key. And once again, that's wrapped with this user key that's under arrived. The data that's, you know, written out to the disc image and back in is just encrypted on the fly. And if you've used that, you've seen that there's actually -- has very good performance characteristics. Even two releases ago when we measured it, it was in within a few percent of disk speed. And now I don't even know what it is. But it's very, very fast.

So one of the things that you are particularly concerned with from an IT perspective is, well, your users have all this encrypted data. And that's good if some attacker gets it. But it's bad if they forget their password. Because guess what, you won't be able to get it either. So as we were thinking about implementing this feature we thought, well, how can we protect the IT organization so that they can recover that user's data. It would be the same issue for a user at home.

So there's a separate keychain that's created -- it's a system-wide keychain. And it contains a public-private key pair. And that provides -- it's used to provide an alternate wrapping for the key that are protecting the user's data. And there are a couple different -- I think we've -- published a couple documents on different ways to create this File Vault master keychain.

The simplest way for a home user is they go to the security control panel and just say create File Vault Master and they'll type in a password. We've also documented methods that are more useful, like, for example, the way we do it at Apple, we generate a five-vault master key chain at a location in our IT department.

They keep a copy of that one that has the private key and they put it on a CD and stuff it in a safe. With the other copy, they remove the private key, an then they push that out, that keychain out, to all the users in Apple. You don't need the private key to create or to wrap the master key. You only need it to decrypt it. So that's a good way of distributing that without having to put, you know, well, leak the password to this -- out to your organization.

So here this slide mentions that, you know, that identity could be -- you could create your own File Vault master key chain, or you could import a key into that keychain. It's just -- it just looks for it by name and it takes the first identity that's in there. So there are a lot of different ways of creating that. It can be store -- you might have your own archive system for that.

Okay. So to get down a little bit deeper into how this is actually working, let's look at the File Vault layout on 10.4. So this is kind of an exploded view of what the data looks like inside a disk image. So you can see the diagram on the well -- well, actually let's look at the bottom part. The bottom part is the encrypted data.

So that's just this mess of bits that is your data. And the next row above that is -- are the different wrappings of the symmetric key. So not shown on this diagram, because we don't want you to think that it's actually in the file, there is a random 128-bit AES key that is actually protecting all that data.

The small blocks above that are different wrappings of that symmetric key. So you can see that on the far left are the wrapping done with the user password. They type in the password. It runs through PBKF-5. And then that's used to unwrap it. The File Vault master keychain, that's the second unwrapping. And there's actually space on 10 4 for I think another 98 keys. So the file format supports 98 more keys that you could unwrap the data with. But there's actually no way to insert those in there.

Okay. So what -- what did we change on 10.5? The major thing we changed there is that we now allow smart card access to your encrypted home directory. Now it's sort of supported before. It's just that there wasn't an automatic tie in. And there were a lot of little loose ends to tie in to make that all work smoothly.

The log in process is very similar. And of course the password based File Vault doesn't go away. You can use that if you like. But if you have a smart card with an encryption key on it, you can use that to create these File Vault images. The user will log in, they will enter their PIN rather than a password. That will unlock the card.

And it will, as part of the log in process, it will also use that smart card to unwrap the keys that are protecting the File Vault. These images can be either AES 128, or 256. And it's the same thing. The data is written and read encrypted on the fly.

The layout here, it's listed as a different diagram, but it is really pretty much the same as 10.4. The data format changed a little bit to improve some reliability. But the main thing is that in the first slot you now have instead of a password you now have a smart card. And so that smart card, one of the -- the encryption key on the smart card is being used to wrap the first slot there, that is wrapping the data. The encrypted data. You still have the second slot where you have the File Vault master key.

So that UK1 is actually a key that's on the smart card which of course never leaves there. But it does cryptographic protocols to say, okay, please, you know, I need to do an unwrap operation. So here you go. Now that -- the File Vault master key, it's listed as optional in the sense -- it's not optional in the sense that you still have to create something using the security press pane. Because the system requires that you have something there.

It is optional in the sense that in some organizations you may already have a hierarchy for escrowing the user's encryption key. And that's all you need in order to be able to recover their data if its lost. So it may be that you don't need to actually have a single master keychain that could be used to recover all these File Vaults.

Now of course you can -- you could put in just as we do at Apple still. A corporate-wide master keychain. And -- or that could be created through your own certificate authority. Or you could put in a junk certificate. In other words, you've confirmed, yep, we have our user's keys escrowed somewhere else. And we don't have to worry about that particular thing. If we need to recover the data we can just create another card.

For example, that's how the DOD common access card works. When they create that card they generate the two sign in keys on the card so those are there for non repudiation. But the encryption key they generate on their secure server. They escrow one copy, and they push one copy to the card. If the user loses the card they have to get a new identity anyway. So they go back and it can retrieve that encryption key and push it back.

Okay. So to enable File Vault in Leopard, File Vault with use with the smart card, you have to turn on the File Vault master password or copy in a keychain that you're going to use. There is a new command line utility called Token Admin. It's only purpose right now is to create a File Vault user. We may enhance that in the future with a little bit more stuff to work with tokens.

And that Token Admen command, or the create -- that's the user command, takes the short user name for the user and a long user name for the user. And then optionally a password for the user's keychain. You'll then display -- you'll insert the user's card and you can display the hashes on the card uses F C Off Script with the hash parameter.

And that will list those long 20-byte hashes o f the smart cards. And then you'll use that hash to bind the user to the account. So as Shawn explained earlier, it's going to look that public hash key up in the directory and say, oh, okay, that's that user. And we will go load that up.

Now the other thing that we added as part of this feature was the ability to unlock the log in keychain with a smart card, or actually any keychain with a smart card. This is -- it's something that you can decide whether you want to enable that or not.

In some cases it may be easier for the user to have a keychain that actually has a password. In other cases you might want to have both. If you want to enable that, though, there are a few more steps that you have to do. So you have to mount the File Vault image file.

So we previously created that user account using the Token Admen command. That creates a file which is user -- it's in the user directory and it's the name of the user, and then user dot sparse bundle. We're going to mount that using HDIutil, so it will actually show one as a drive.

We can then use a new option to the system keychain command to protect that -- that keychain -- with the smart card. So it will link those two together. And then as the last step, so you can allow the user to actually log in. You need to unmount that image. Because the user won't be able to -- it won't be able to be mounted twice. So if you forget that step the user won't be able to log in.

Okay now, a couple of things to keep in mind about this. This is kind of the first -- it was a very, very big feature to implement. And it has -- it has a limited scope. We know people really wanted this feature, so we worked on it and we it deployed it. It's particularly useful for people that are travelling that have a portable, and they want to secure that.

It -- we do not have any way right now to migrate an existing account. So this command will only allow you to create a completely new account on the machine. So you can imagine -- you -- you -- you know, you get your new MacBook, take it out. You want to set up an Admin account, which is not the main account. So that will be a separate account. Then you'll run through these steps and you will create this File Vault user.

And -- you really want to have the second or primary Admin account. Because we still -- we do not have every single authorization dialogue -- Shawn showed you some of them. And many of the dialogues are hooked up. We do not have 100 Admin access with -- via smart card yet. So Leopard does not have that. You will, unfortunately, will still need a separate Admin account.

If you have -- had data on that machine that you're then copying into this new user, you may want to securely erase it. But probably a better way to deploy it is take this completely fresh lap top that has no user data on it, configure it, then add the user's data in from, say, an external FireWire drive.

Okay. So unlocking smart cards, or unlocking keychains with smart cards -- as I mentioned earlier, this is something that you might want to set up for the File Vault user, and through an addition to the system key chain command you can associate a keychain with a token that you want to use to unlock it.

If you do use the joint system keychain, you will see system key change dash C, which creates your system root keychain. System keychain dash T will protect a keychain with a token. So instead of using the -- instead of using the user's password to derive a key, which is then used to unwrap the data in the keychain, it uses the key on the card. It uses the currently inserted card, and it picks the first encryption identity on there. So that's a limitation on that command. So now I'll give you a quick demo of this working. Okay. I'm going switch to Demo Machine B. Okay.

And I have previously set up the File Vault master keychain. Oops. Wrong one here. Security. File Vault. So you can see it says a master password is set for this computer. So I just set that up earlier. That's a step that you have to do first. So the first thing we'll do is we'll -- actually very first thing we'll do is insert our card so have a -- this is a common access card that as Shawn said has an identity cert, signing cert, and encryption cert on it. Of course, the encryption cert is essential to make the File Vault work. Because it needs to be able to encrypt and decrypt the data.

So we'll insert that card. You can see that it's there. Security list will show you a list of all the keychains. And it's the first keychain in the list. And of course Keychain Access will show that to you as well. So you can see that's up there. So now we'll go ahead and we'll create our File Vault user, using the Token Admin command.

And I'll hit return on that. Now it -- it goes through and it validates that the user exists and doesn't -- or doesn't already exists, and is allowed to the created. And then it goes ahead and creates the home directory. Now it's going to ask me for the PIN.

And this actually takes a little bit of time as it sets up all the data structures. I think -- I think the initial file is a couple of Megs anyway. So it's doing all the directory. Okay. So now if you looked at Slash Users, we'll see there is -- there's a J.Coltrane user there. And if you look in that directory you will see J. Coltrane dot sparse bundle.

Okay. So now the next thing we want to do is we want to associate that user with -- with that account. Or we want to associate this particular smart card and a particular identity cert on that card with the user's account. So I am going use the identity private key here. That's this first one here. And that's assigning key.

And I use the Cs Off Script with the Accept parameter. So it takes the short name of the user and the dash H parameter is the hash. So at that point the user is all set. If you logged out now, the user could log in. But let's do one more thing. Let's protect their log in keychain with this token. So we've mounted the sparse bundle. And we associate using the system keychain. We associate this card with that keychain. And then as the final step we will unmount that volume.

Okay. Now at this point we can go to log in window. And you'll see that the smart card sniffer's running there. It realizes that the card is inserted. The card is associated with this user through the hash value. And it says, oh, okay, we know who that guy is. All we need now is his PIN.

Now this one -- this dialogue you will not see in the final release. This is a known bug where it asks for it twice. Normally the user would just type that PIN once. And there they go. Now they're into their File Vault at Home Directory. Now if we look at -- if we look at Keychain Access it will show you all keychains. So one thing you see the smart card keychain is in there.

And then -- there's their log in keychain. And because we've already unlocked the smart card using the PIN, we don't have to provide a password to unlock that log in keychain. It's already protected with, you know, with the token. And we could add items to that and, you know, just like a normal keychain.

Very, very bad password. There you can see the password assistant. If you click on this link of course it will bring up the full thing. And definitely encourage your users to use that if they are still using a password based thing. Now one thing to realize about this log in keychain -- these -- as you're adding -- if you add passwords these are not going out to the smart card. This is a file-based keychain inside the user's home directory. But the encryption is provided through the card. So those things are wrapped with the card. Okay. So that's it for the demo. And I think we're back to the slides.

And then I would like to invite Shawn back up to -- take it away.

How does it really benefit my user, my customer base. The key take-away from all this is the fact that since we abstracted those smart cards right into the credential environment, into keychain, all of your applications that are leveraging our security services for these -- for these -- for certificate use and key use and all here -- can be requesting those objects and relying on the fact that they could potentially be a file-based keychain, or they could potentially be a smart card-based keychain.

Right? As you saw each time we added a card, it dynamically added a new keychain. The applications themselves should really not have to deal with, is this a smart card I have to interface with? On other platforms they have to specifically target and develop towards the card. Here we've taken the approach that with the proper abstraction on those cards right into the OS, your applications that you're developing or the applications that your users are leveraging should not really care, for the most part, whether it's coming from a file-based or from a smart card-based. So hopefully this gives you a good overview and a little bit in depth on certain aspects on the use of smart cards an how they can help in your environment.

So again, to kind of summarize some of the things that we have shared with you today is hopefully you're seeing about the use of two-factor authentication, smart cards for something you have and something you know to provide that secure and reliable form of authentication. To help you meet some of those mandates. Help you meet some of the requirements you have in your own IT environment. The extensive support that we have in the OS, particularly with the addition of the unlock of File Vaults and with keychains.

And the support that we have out of the box for -- in Leopard coming with PIV, but already that was there in 10.4 was the CAC, the Belpic, and JPKI. And there are several smart card vendors that we've been working with over the last couple of years that are already providing access to their proprietary cards through their own Token Ds. And many of them already have those available on the market.

Some of them haven't really promoted that capability probably as much as you and we would like. So you may want to do some inquiries. Either with -- directly with the smart card vendors or even some of us, if you're looking for some of the other card availability . So for more information on this if you're on the developer's side, of course your perfect resource on this is Craig Keithley directly for developers for the security technology evangelist that Craig is. If you are kind of on the IT enterprise customer-side, I can be a very good resource for you on that. And so we kind of cover bother aspects of -- kind of interfacing with all of you that might be here today.

Two areas that are really kind of an extension and more of a clarification in some of these areas that we covered today. Later on is Understanding PKI and Certificate Management on OS X. That too has -- has had some significant enhancements in 10.5 -- in Leopard. And then later on, on Friday, is leveraging this all related specifically with remote access and some of your infrastructure there.