I'm Craig Keithley. I'm the Security and Cryptography Technology Manager. I have another role, which is also USB and FireWire Technology Manager. So if you've seen me in the USB and FireWire sessions, I do that too. And there's actually a little bit of an overlap. There's a number of security dongles that are USB-based. So I take my skills from USB and I apply them to those as well.

Today we're going to be talking about security in Mac OS X from a high-level kind of point of view. We'll be talking about the new features that have been added. One of the things I'm really pleased to be able to say is that starting with 10.0.3, we now have PCSE, or Smart Card Support, built into the operating system. So without much further ado, I'll bring up John Hurley, who will give you the presentation on Security Overview. Thanks.

Okay, good morning everyone. Good to have you all here. I'm going to try and give you an overview of the new security features that we put into OS X. We've been really excited to be able to work with X. It's given us a lot of new possibilities. I mean, really the chance to actually start working towards a secure OS. So that's been great for us to work on.

We have a lot of developer-related features as well, so I'll try and indicate some of those. And we have sessions going on the rest of the week. And we're going to start today as well with some of these things. I guess one of our biggest... The idea behind the messages or design goals really is that we're trying to make the security in OS X configurable.

So the default out-of-the-box thing that goes to the home user or whatever is going to have one configuration. And ideally they won't even really think for two seconds about security. It should just kind of be in the background. But we want to be able to enable all these other markets that really are interested in security and see Mac OS X as a great platform to implement that on.

OK, so I'll talk about our architecture for data security.

Okay, so some of the opportunities that we've been able to really leverage on with OS X that we never had available to us before. Probably the biggest thing maybe is protected memory. We can have memory that's in a particular process and, you know, unless you have root access, you can't actually see that memory. You can't really get to it. So we have, for example, we have a process called the security server, which contains the keys as they're used.

And being able to leverage that is really great. It gives us a good chance to make things more secure. Being able to take advantage of the multitasking stuff means we can do things, we don't have to worry about being preempted or worrying about other processes that need to run. One really big advantage is that we have this whole BSD infrastructure that we can build on. We can do security work that's been done on standard, you know, Unix level security. And wherever appropriate, we've taken advantage of that.

Maybe one of the biggest things is that we've been able to have a fresh start. Of course, Classic still supports the OS 9 environment, but being able to move to this completely different operating system meant that we could kind of shake things up a little bit. And some of the things that had kind of gelled over the years, we were able to get in at the beginning and start really implementing security from the beginning.

Okay, now the last bullet here is the announcement. And this is really, we've been wanting to do this for a really long time and we finally pulled it all together. So the announcement is that we're making most of our data security components open source. So they will be available.

We're really happy about it because it just gives us so many advantages. One of the things with security is peer review. You can't do security through obscurity. You have to have people being able to look at the code and try and find holes. So it's great that we're able to do this. We've open sourced pretty much everything that makes sense from a Darwin perspective. So the idea is that if you have your Darwin system, you can compile that. These are all the components that you could compile in.

and get working without-- it doesn't have, say, the high level UI components, but all the low level stuff, all the cryptography, the CDSA plug-in modules-- actually the next slide sort of talks about that. It makes it a little bit easier for us to do export compliance. And the last point is really important. We really value your contributions. I mean, the open source community has been great in looking over things and providing suggestions and code and whatever. So we're really looking forward to getting that input from all of you out there.

So in more detail, the things that we're making open source, the security.framework, all the subprojects of that, so the authorization subframework, secure transport, which is our SSL implementation that ties into CDSA and all that, so that's in there. Keychain, not the highest level APIs because those are actually in Carbon, so that's not open source, but you can do all the Keychain functionality with these lower level APIs and the code for security server.

All of the plug-in modules for CDSA, so the data library and cryptographic service provider. There's some ASN1 code. There's a lot of good utility code. There's a lot of really, really good stuff in there, so we're really excited to be able to make that available. I'll just have to mention what the web page is because this just went live last night, so of course it didn't make it on the slides, but if you go to www.opensource.apple.com, you can find the little blurb on security, and that tells you where you can get the source from and all that.

Okay, so talking just briefly about the Keychain, this is a feature that a lot of you will be familiar with from OS 9. A lot of the look and feel of it is very much the same as it was on 9. I think the biggest thing to realize is that on OS X, every single user has a Keychain. So you can pretty much count on that.

I mean, even on 9, if they didn't have one and you used it, it would come up and give them the dialog to create one. But on 10, when they log in, they have a default Keychain that's created with their login password. And all the system services use that to store their passwords.

So, for example, mail or... or, um, um, I can't think of the other ones now, but anyway, with iTools and whatever. So all those passwords are stored in the user's keychain. And we've actually done a really good job of kind of making that transparent. So you log in. By default, it's unlocked throughout the whole time that you are logged in.

But of course, you can change that setting so that it automatically locks or whatever. The idea is to make it as simple as possible kind of for the average user. But if you're more security conscious, you can do things like Make it lock more frequently. The biggest message that I have to say about that-- and of course, Ken will go into real detail about how to use it.

Biggest message I have is if you are saving-- if you need to save a password, use the keychain to do it. It's really, really easy. You only need basically two calls. You find it to see if it's there, and if it's not there already, you can add it. That's it. And it's a very, very small amount of code.

It will save you perhaps some embarrassment if you didn't quite implement it right. I mean, we've gone to a lot of trouble to make sure that the keychain file is protected, and applications that are not allowed to use a particular password will either warn the user or prevent them from doing so.

So we put in a lot of work. It's easy for you to use it. So that's my big message to you, is just use it. If you have passwords, store them there. As I said, it's mostly transparent to the users. We've really changed a lot since OS 9.

Probably a lot of you are familiar with the old rogue app alert that would pop up a lot. But we've managed to-- because of the capabilities of OS 10, we've finally been able to do that kind of the right way. And so the rogue app alert just doesn't show up. It really only shows up when it's supposed to. And it's an API that's available through Carbon. Or you can now also call these lower level APIs that are part of the open source.

Okay, a completely new API that we've introduced on X is the Authorization API. And I think right after this session, Michael Brower is doing a complete walkthrough of all the API calls and all that. But I did want to spend some time here just so that people at least understand why we did that and why it might be worth your while to go to the next session to hear more about it.

One thing we realized looking at, well, even on 9, but particularly on 10, there are a lot of places where the user needs to, say, enter their admin password to do something. So we've kind of... So, I've locked it down a little bit so that you can't accidentally make a mistake or whatever.

But initially, Different groups at Apple were kind of doing it a different way, and they would check it here, and there was no real central way. So one thing we did was we kind of went around to all the groups and said, okay, let's funnel through this one bottleneck, and with the idea that for any given operation that you're doing, you can basically find out from the user or find out from some settings that maybe the administrator or the machine has configured, you can find out whether they are allowed to do that operation at that time.

And bottlenecking it through one spot allows us to do a lot of great things like being able to, say, cache the password for five minutes or something like that. It just kind of streamlines it a little bit for the user so they're not typing this password in all the time. So from a really high level, the Authorization API is basically trying to answer a yes-no question.

Given an operation, am I allowed to do it right now? I guess the really interesting part comes through maybe the side effects, which is, okay, how do you figure out whether they are allowed to do that or not? And one of the basic side effects that can happen there is it may call off to these plugin modules that we have to do different types of authentication.

So, Let's take the really, really simple example of if you have the Prefs panel, you have the little lock. You just want to know whether you are allowed to turn on your screensaver or something. If you click on that lock, it might do a very simple authentication thing. It might say, oh, is this user the administrator of that machine and does the password match? Okay, you're allowed to do it.

But through this API, we've set it up so that you can plug in different modules and those could get evaluated and return, you know, ask for different types of authentication from the user. For example, as Craig mentioned with the PCSC stuff, now we can do smart card stuff.

So you could be getting information off a smart card or voice print or fingerprint, whatever. There are a lot of different things that you can do. And it's set up so that you can do a lot of different things. And it's set up so that you can chain a whole bunch of these together and get answers from each one of them.

I guess one other thing that I want to point out is that it's not, this is not, it does not give you the ability to do a particular operation. It's kind of assumed that it's being called from a trusted app that could do it anyway. So it's really, in a way, it's really a convenience or a service to the user that you are asking the user whether or not you're allowed to do this operation.

Because, of course, if it wasn't a trusted process, they could just, well, not call the API and just bypass all that authentication stuff. So that's something to keep in mind, that that's, it's not really providing the capability. And as Michael will say later on, you'll end up needing to have probably a set UID root tool or something like that that can do, if that's what would be required for the operation.

The authentication modules could do a couple different things. They might figure out who you are. So, for example, look you up in some directory services database or net info or whatever. Or it could be looking at, say, a fingerprint reader. The three things I list there are kind of the security questions that you want to find out about authentication. Could be who you are. So, that's actually something like a fingerprint. What you know would be like a password and what you have might be something like a smart card. So, if you have all three of those together, then you've really added some security to the system.

One other thing with these authentication modules is that they may generate some sideband information that's needed either for the next module down the line or for the ultimate service that may need something. Like, for example, let's say you're logging in with Kerberos. You need to know not only username and password, but you also need to know the realm. So, that would be... Those would be things that would get passed along so that at the end of the operation you would know what you need to know to move forward.

And then the last point is, in a lot of cases, this operation might just succeed. Like the answer to the question, you know, can I do this operation? The answer is always yes. It never does anything, never throws a dialogue, never asks the user at all. The point is that you can configure it for these different operations. So if you're in a more secure setup, you could, you know, lock that down more. So we're, you know, we're moving towards getting all that stuff working nicely.

Okay, so just an example of probably maybe a typical operation you might think of for authorization. Let's say you're logging into the console. You could have several different steps that you might have to go through. So you might have to type in your username and password. The username, for example, can go look off in a directory somewhere and figure out where your home directory is and all that. The password, ideally you want to ask the user for that because then they can unlock the keychain. You might have to insert a smart card or fingerprint reader or voice recognition.

Some of the operations that you might be able to do, I mean logging in is an obvious one, but Unlocking the screen saver. You know, it would be nice to be able to step up to your machine and as you walk back to your office say, hey, I'm back, and have the screen saver just unlock without having to type a password. Playing a CD is something that comes up a lot in K-12 market.

The teachers want to restrict what CDs the kids can play. So that's an operation that we can, by calling the Authorization API, you could set it up to configure it so it could go off and look up in a playlist whether or not it's actually allowed to play that CD. and Formatted Disk.

That's kind of a good one to turn on for your kindergarten kids so that they don't format your stuff. Okay, so anyway, there's a more detailed session on that next after this. CDSA is the foundation for this security architecture that I've been talking about. The Keychain is based on it. The secure transport stuff uses all that. All the cryptography stuff that we do goes through this.

It stands for Common Data Security Architecture. Originally it came from Intel, but now it's an open group standard. On OS 9 we implemented the 1.2 version of the standard. We learned a lot from doing that and contributed a lot to the So that's what is in OS X is the 2.0 standard.

I guess one of the biggest features that stands out about CDSA is that it uses plug-in modules to do a lot of the work. So, for example, the Data Library module or CSP, Cryptographic Service Provider, you can plug in, you can write a module to do different types of crypto. Certificate Library and Trust Policy module.

Here's kind of a really rough block diagram of how these things are laid out. Kind of the pieces in purple at the bottom are the plug-in modules, and the CSSM layer is the kind of guts of it that loads the different modules and helps them interact with each other.

The layers in red are just some of the sort of middle layers that we've written on top of the CDSA APIs. CDSA is a pretty extensive standard. I mean, the manual is about that thick, you know, like 1,300 pages. So there's tons and tons of APIs, but we found that when we were using them, we kind of tended to group them together and, you know, maybe use them in a particular way.

So a lot of the stuff that you would see in... in Security Core, for example, which you can see in the open source archive, those are collecting together these CDSA functions. Security HI is the user interface stuff that you might see, like the dialog that pops up to enter your password. Secure Transport is our SSL implementation that uses our certificate libraries and things like that. And then, you know, you can write apps on top of that.

I guess the biggest point is that if you're writing to the APIs on top, even if the plugin stuff changes below, your application isn't going to have to change. So you can really leverage as people develop more stuff below. Your app can just, you know, if there's suddenly a hardware crypto module, then you could take advantage of that.

So, the keychain is basically the Apple file CSP DL. So, it's a combination of cryptographic service provider and data library module. And that way, when we write the keys out to the file, we can do the encryption at the same time. We could have done it as maybe separate ones, but it just turned out to be a separate module.

to be convenient to put it in one module. Another example of a DL that we don't have now but would be not too hard to write would be an LDAP DL. So you could store things, particularly say certificates or something like that, you could store them in a public LDAP directory.

Certificate Library Modules. Roughly it just knows how to parse a public key certificate. So the one that we ship by default does X.509 version 3 certificates. For a particular field in the certificate, the layers up above can ask, okay, what's the modification date on this or who signed it or whatever, and the certificate library knows where in the certificate to grab that value. It would be possible to write one that would know how to deal with a PGP certificate or attribute certificates, which contain, it's basically a way to take a bunch of attributes about something and then sign it so that it's a little bit more certified maybe.

Trust Policy Modules. This is an interesting one because I think this is one that a lot of corporations or universities might be interested in writing because the standard one that we ship, Basically says, okay, given a certificate, how do you know whether or not the user trusts that? And so the standard one that we ship for X.509, we look, given a certificate, we see who signed it, and then we see who signed that, and finally we get down to a list of trusted root certificates. And if it matches one of those root certificates, then we say, okay, it's trusted.

But it could be that you don't necessarily want to do it that way. One example there is you could do a web of trust. So you could say, okay, I'm only going to trust it if my pal trusted it. And so that would be a different way to implement a TP. Or you could go look it up in a corporate database. So there's a lot of different ways that you can change how certificates are trusted on the system. by writing a trust policy module.

I think the SDK is posted on the security page, so for actually developing it, that's available there. We wanted to make sure that it was easy using this API to get to the CDSA APIs and try and make it pretty easy if you had an application that was already using PCSC on another platform, you'd at least be able to bring over that portion of the code pretty easily onto 10.

We tried really, really hard to make it very easy to write a driver for the different readers and there are several manufacturers that have already completed drivers for different smart card readers. And for different types of smart cards, you can actually write a different CSP to deal with to use the cryptography that might be on the card.

Here's kind of a complicated diagram with how this all fits together. You can see down at the bottom that the readers and the cards are down there. The idea is basically that you have the applications at the top and if they're calling through these APIs, they don't really need to know any of the details. I mean, PCSC can deal with, it deals with all the resource management.

So, for example, if you have a If you're in a situation where you have like 10 different readers plugged in and they all have different kinds of cards and whatever, this sorts it all out. It knows whether several applications can talk to a particular reader at once or whatever. So all those details are basically taken care of for you.

This is an area, of course, that a lot of you, if you're familiar with Unix, then you know a lot of these things, security features that you can use. Basically, OS X ships with most of the services turned off. So, you know, FTP and Telnet, things like that. The average user, the average Macintosh customer, you know, if they're not familiar with that, it's safer to just leave it off. If they find out, or if they're interested, they can go and re-enable that.

We turn off the root password by default, but that can be re-enabled. And I think that was one of the very common questions. People weren't complaining that we had turned off root, they just wanted to know how to turn it back on again. So there's a Tech Info library note on that if you search the TIL database, you can find that.

File permissions has been one of the areas that's been pretty tricky to figure out. And I think roughly the basic goal is we're trying to make sure that it works the right way with OS 9. And so a lot of those things are... Maybe not set the way that you're used to, say, from another Unix system, but and John Hurley. They're set up to work, to interoperate with Classic and things like that.

I guess the biggest thing is there are a lot of different books on Unix security, and most of those things apply on Mac OS X. So I would say look to the resources that you know from that area. We try and keep things pretty much standard if we can at that level. And as we hook it more up into the upper levels, well, we try and keep the behavior pretty much the same as you're used to. I think they talked a little bit more about this in the BSD session too.

So here are some of the resources for these things that are available. The security webpage at developer.apple.com has some good links off to our software and to some other links that are interesting. can find the specifications for CDSA at the Open Group. We also have a pointer there on the security web page. And as I mentioned, the www.opensource.apple.com has our source.

Oh, that's, sorry. Again, here's another thing that just came up, so it's not on the slides, but I'm glad I remembered to talk about it. We have posted a security webpage. A lot of people had kind of been wondering, you know, how we would deal with things like cert advisories and just security holes that might pop up in OS X. So, sorry that this isn't on the slide, but again, this page went live yesterday. So, if you go to www.apple.com slash support slash security.

and then security.html. That has a whole page that is designed for people that have, they think they've found a security problem with OS X or they may need some security assistance. And that page contains the resources that kind of tell you how to So, it's a central point for kind of reporting problems. We have a team within Apple, so that stuff gets distributed, you know, really immediately.

And we, depending, it gets routed to a lot of different groups. Each group will kind of look at it and determine if it's something that is in their area of responsibility. And we'll try and fix it as quickly as possible. We, of course, have the software update mechanism, so we have been able to actually already release some fixes in each of the software updates that's gone out so far.

I think we pretty much shipped

Here are some of the related sessions that I mentioned. Right after this is the Authorization API session. At 2 o'clock is the session on the Keychain, learning how to use that. Tomorrow afternoon, there's a session on Kerberos. We'll talk about what we're doing with Kerberos. And on Friday, there's the feedback forum.

I think you can also find that on the web page. If you have any questions, particularly if you're interested in developing security related products, he can find all the right resources for you.