Good morning. Welcome to our session. Today we're going to be talking about, well, network security best practices for OS X. Before we get going, I just want to do a little housekeeping and introduce my co-presenters. So rather than you having to hear me for an hour drone on about OS X, I have some cast members over here and I'll introduce them in order of appearance because I don't think we do that on the slides. First coming up will be David O'Rourke. David's one of our engineering managers and David's responsible for directory services and authentication within OS X.

After Dave, we'll have John Hurley. John is our security policy architect for OS X. And John just recently became a famous Apple employee. He doesn't know I'm going to do this. John is actually the only Apple employee I think ever to get his picture in the OS. I don't think Steve has even been able to do this. If you poke around, you might be able to find it later. Maybe we'll have a prize whoever can find John by the end of this session. And then finally, Sean Geddes will be joining us. And then finally, Sean Geddes will be joining us.

So I think the best way to frame this discussion today is to just admit that you're all intelligent people and you know your networks better than anybody else. And they're all very different. Some are standalone networks, don't require any passwords at all. Some have light security requirements. Others are very heavy, globally dispersed, VPN access, Kerberos requirements for authentication.

So rather than to tell you this is the way to plug it into this particular network, we're going to let you make that decision yourself and let you, arm you with the information rather, to give you the tools, let you know what's in OS X so you can go back and make the right decisions for your own network.

So when we talk about network security at Apple, this is the definition we work from here. There's many varied definitions out there. Also, if you look at, you do a little web research on network security, you'll find all kinds. Varied things, different policies, ways you set up your policies, all the way down to how to secure your firewall. So this is what we're going to work with today.

So the focus at Apple first is really communication and data security. For us, it's about not just storage of your information, keeping that secure, but rather how it traverses the network too. So the data is what we're really trying to secure and how do we do that. First, we control access to it, to system and services through authentication and authorization. And then finally, the management of that access, which is very important.

So our design philosophy is really put it in at the core. Let's not put it on later on. Let's build it right in. OS X was a brand new operating system and allowed us to really take a look at it. And our security policy architect, John, was very instrumental in that.

We took the conservative approach. This, surprisingly, is fairly new. Most folks didn't lock down the ports. We'll get into more of this later. But a lot of new installs of some very famous operating systems, I won't mention them here, are quite open to exploits right out of the box. The OS, open source. So everybody here can look at the code and make sure it's secure. There's no back doors.

That can be verified. Open standards. Why are they good? We'll get into that later as well. And, of course, the Apple trademark, easy to use and manage. If security is not easy, it just won't be used. People will just turn it off, and that's no good. So you've got to make it easy to use.

So like I said, security at the core of the OS. At the core is Unix. So we leverage the Unix core that's already in there with the file permissions, the services are built right in, your home directories and file permissions are all set to segregate your information from other users. Multiple accounts is built right in, and then protected memory. So if a rogue app gets a hold of the system, it's not going to crash it by taking over the memory.

Like I said, conservative defaults. Services are off by default. No FTP servers. Web servers are off. All ports are closed. It's locked down. The root account is disabled.

So what is true security? There's a famous quote here from Bruce. What I believe is what Bruce is trying to tell us is that physical security is paramount. The basis for all security is physical security. Once that's compromised, once somebody gets a hold of your machine, it's all over. You may have the best encryption on there in the world, but if I hit it with a sledgehammer, there goes your data.

So let's talk about the physical security within OS X, and also there's some enhancements OS X has for physical security and Apple's security built into its products. Of course, you can lock the cases so they don't get removed. Apple has a lot of experience in the education market, and things tend to disappear from universities. Maybe the kids are just borrowing them. I don't know.

Once you lock it, you can protect the memory, protect all the critical components of that computer, and it protects the firmware settings, which we'll talk about in just a second. And then server. Server's got a lot of neat security features. If the front of the case is locked, you can't mount FireWire hard drives, you can't mount USB. Also, there's a monitoring system in it, so if the case becomes open, it can alert you to that. Thank you.

So open firmware security. Just by a show of hands, I can kind of see you out there. Does anybody know about open firmware security? Oh, great, a bunch of you. So I can't say enough about this. This really enhances physical security. So if, for those of you who don't know, it's analogous to the Windows BIOS password lock, analogous. But it disables the snag keys from startup.

So if I turn on open firmware security, which is a free download from apple.com, you can't boot off of a security. You can't boot off of a network drive. I won't even mount. It won't turn it into target mode, which can be kind of a security problem if the thing just turns into a FireWire hard drive. A little laughter up front, yeah.

By the way, it said down there it's a superset of IEEE 1275, and a little trivia, IEEE 1275 is the only standard to have its own song. I don't know if you knew that. You go to the website and you can listen to it. So the security services within OS X, like I said before, authorization, authentication, we have the crypto built in, and the certificate handling. John will jump into that in a lot of depth and give you a good understanding of that. But that's really the core around, the wrapper, if you will, around the Unix core.

So authorization controls, once I figure out who that user is, what can I let them do within the system? We've got a couple nifty little apps built into server and the desktop itself. Some may or may not be familiar with, but you can limit what the users can do. As you know, ROS has, you have an admin and you have a user, if you will, but you can tweak the controls to limit really what's going on within that OS. We'll go into that as well.

So as you can see here, just for a user, this is just local, and Dave will get into more of the global, more scalable authentication, or excuse me, authorization and authentication. But you can see you can limit what the user does. So in a very small shop, this is a great way to keep people from hacking their machines or the network themselves, so you don't have to go back and redo what they've done, repair the damage. So now I'll bring up Dave. Thank you. Sure.

For those of you who haven't seen me too much this conference, my name is David O'Rourke. I'm going to be here to briefly go over authentication and directory services. We went into a lot more detail on these topics in session 607 and 610. If you didn't have an opportunity to catch me, I'd recommend you get the developer DVDs. We go into a lot of excellent detail, and we're going to be going over things that are pretty high level at this point. Thank you.

So authentication services. Most, if you type a password into Mac OS X, 99 times out of 100, it will flow all the way down and hit directory services. So all password authentication is done using the open directory architecture. The reason we do that is we want, not only does Apple want to provide a variety of ways for users' passwords to be authenticated, but we also want you to be able to plug into the open directory architecture and authenticate users however you see fit for your site. So it's both a solution for Apple and an opportunity for developers and customers.

What Apple provides in terms of network-based authentication is we provide a password server, which provides support for legacy authentication protocols. This is secure on the network. You cannot download hashes. The only authentication methods it supports are secure challenge response authentications. And as you may have heard at the conference once or twice, we're offering and really going forward with Kerberos. So moving forward, we take authentication services on the network very seriously. We're integrating them into open directory.

We already offer some very credible and very good authentication services. We're also offering a lot of security around the password server, and we're moving aggressively into the Kerberos space. For enterprise architecture, again, Open Directory enables integration with existing directory services. We support LDAP, we support NIS or Yellow Pages, for those of you who have been around quite a while, NetInfo, Active Directory, and local BSD configuration files.

The Open Directory Server is a LDAP server that offers SSL support. It is based on OpenLDAP 2.18 currently, is what you have on your Panther build. We'll be investigating, updating to the latest builds. I've heard there's some later builds of OpenLDAP. We have a very easy-to-use open setup assistant. It's like three clicks to deploy an LDAP server, and it's entirely based on OpenLDAP. You can download the source. You can look at it. We have some changes. All of the changes will be posted back to the Darwin website.

For those of you not, who didn't get a chance to go to session 610, this is the open directory architecture. The blue boxes at the bottom would represent applications such as login window or maybe the authentication dialogue that comes up when you click on the lock icon in system preferences. Most of the time, those end up calling the open directory APIs. The open directory APIs figure out which plug-in is hosting that user record, and then we engage with whatever directory system has been configured to conduct an authentication.

Our authentication is no better or no worse than the directory system that you deploy at your site. If you're comfortable with the directory system that you've deployed at your site, the authentication method that's using open directory is exactly as secure as that deployment. If your directory system is not secure, open directory cannot add security to that environment.

So you can have a mix of clients. You can have Macintoshes on the network sharing directory data. You can distribute the directories and force the Macintoshes to use a particular directory system through your DHCP infrastructure. LDAP can be there. We have the authentication authority record, which lets you actually mix user records in the directory. So you could have some users that are crypt-based.

You could have some users that are password server-based, and you could have some users that are Kerberos-based. The authentication authority lets you pick the appropriate security for your user records at your site. And home directories can be mounted over authenticated protocols. We already support AFP-authenticated home directories. We support SMB and Panther SMB home directories. So you're not mounting home directories over NFS, which I've heard historically may have some security concerns.

The open directory authentication is entirely standards-based. The password server is not something we built from scratch. It is something we built from scratch around an open source protocol, and that protocol was Sassl. Sassl is very secure. It doesn't support clear text authentication. Well, it can, but we've removed it. And you can add, it's modular, and you can add new authentication methods to the Sassl server without a lot of effort.

The password server also provides policy enforcement. How many of you have policy enforcement at your site? You want the users to change every 30 days, minimum password length, character set enforcement, must contain a symbol. Wow, for a security conference, I want to see more hands. So you need to deploy the open directory password server. We can do all of those security enforcements and make sure that the passwords your users are choosing are not guessable, have high quality, and are changed frequently enough to matter. The password server will also disable inactive accounts.

Say you have a contractor on site and he hasn't logged on in the past three weeks, and you don't want him coming back and logging on without checking with you first. You can set up the password server to disable inactive accounts that haven't logged on recently. The password server also provides one very unique feature, which is you have the same password for multiple services. If you deploy multiple Mac OS X servers or other servers and point them at our LDAP server with password server, you get one password for all of your services.

You get the same password for IMAP as you get for AFP as you get for SMB. They don't even have to be deployed on the same physical server. So that means the password quality that you're enforcing in one protocol carries over to the other protocols. That means when the account is disabled, it's disabled for all of the protocols. Thank you.

Kerberos. How many people have Kerberos deployed at their site? Yes. We are going with Kerberos in a very big way. Kerberos, I believe, stands for the three-headed dog that guards the gates of hell. I thought that was a very interesting choice by the original Kerberos team as their product. We are basing all of our Kerberos work on MIT's Kerberos work. We simply take the MIT source code, enhance it, and integrate it with our work.

This is going to be Apple's single sign-on strategy moving forward. Next year, you're going to hear even more about Kerberos. We're aggressively Kerberizing a lot of applications. We already have Kerberized Mail. There's a third-party product for Fetch for Kerberized FTP. Telnet is Kerberized, although we turn it off. AFP is Kerberized. And in Panther, SMB is Kerberized. And what's not on this list is Panther is going to have Kerberized SSH.

So look for more Kerberized protocols coming from Apple. Look for a Kerberos server in Panther server. You will be able to deploy a Kerberos server with the same amount of clicks as it takes to deploy an LDAP server because you won't have a choice. If you turn on the LDAP server, you have also deployed a Kerberos server.

Workgroup Manager. How many of you use Managed Desktop? Okay. For those of you who have already used it, you've recognized that you can put all of your policy management information in the directory. So you can have your LDAP directory host your dock preferences, your security preferences. Well, the tool that you use to modify those preferences and force your users into those architectures is Workgroup Manager.

Workgroup Manager allows you to manage groups, users, and computers. You can enforce privileges per computer, you can enforce privileges per workgroup, and you can enforce privileges per user. It controls access to software, hardware, and network resources, so I can control which applications a user can and can't run. Many K-12 sites disable the student's launching terminal.

If they can't run terminal, they can't run command line tools, it kind of limits their ability to hack around in the system. You can manage system preferences. You can manage which system preferences a user can do. You can force energy saver settings, a whole ton of things. There's a whole session on the details of managed desktop. I recommend you look at it. But WorkRoot Manager is our directory-based tool that lets you do that. And because WorkRoot Manager is based on open directory, you can put those preferences into any directory system that you've deployed.

We store it in our LDAPv3 server, but if you configure open LDAP to, or if you configure open directory to point at a different directory server, you can use WorkRoot Manager to get the Mac OS X policy information into the directory server of your choice. We have one customer we're working with who's writing a plug-in for open directory to Oracle.

He's going to make the plug-in read-write. He's going to use WorkRoot Manager to shove policy information into his Oracle database to manage his desktops. So what I'd like to do at this time is bring up John Hurley to talk about security services, and I thank you for your time.

Great. Thanks, Dave. As Eric mentioned, I'm John Hurley, the security policy architect, and I'll go over actually at a pretty high level some of the different security pieces that we have sort of at the lower level of the OS. We have had a couple of sessions already, one on Monday on security overview and another session, I think, yesterday on certificate APIs. We have a feedback forum this afternoon, so just a few other pointers.

So kind of the core of, I guess it's really our middle layer of security, is the common data security architecture. And this is an open group standard that was originally developed by Intel that we actually used on OS 9 and have continued to use in OS X. We've implemented the 2.1 version of the spec. And this is responsible for doing all the cryptography, the certificates, things like that. So that's a very important building block for the security on our system.

We have, rather than just taking this one set of APIs and just sort of pushing that out as a very extensive set of APIs, we've added another layer on top of that that we call layered services to try and make it easy for developers to use these services without having to know all the gory details down below.

So, for example, Keychain is all built kind of on top of this higher level. A lot of things that you may not think about, say, for example, Safari, that is calling through to secure transport, which calls through to CDSA. And so if you're changing things in the certificate root cert database down below, that's going to be used by Safari. It's going to be used by anybody else that's using those APIs.

So we're really encouraging developers to use those APIs. So that they can get the consistent experience for their users. It is a very customizable API. You can write different modules to do different things. For example, different security trust policies for certificates. Perry went into pretty good detail of that.

You can check that out on the DVDs. We have done... Almost everything that's in there that's not UI is open source. So if you want to see how we did something, say the authorization framework or how we did secure transport, that stuff is available in the Darwin repository.

So here's kind of a simplified overview of how CDSA is put together, and you can see the different layers that we have there. The bottom layer are the plug-in modules. Cryptographic service providers are, excuse me, they implement all the different cryptography algorithms, AES, triple DES, things like that, you know, hashes like SHA-1 and MD5.

Certificate library and trust policy module deal with managing and

So here's just one example of the certificate UI. It's kind of a portion of a screenshot there. But we have put in really good support on Panther for dealing with certificates. And something that I'm really happy with, we did the best we could for Jaguar. We tried to get a useful subset, but it's just very, very difficult to implement this full standard and really get it working the way it should.

It's not the way that Mac users expect, you know, just very, very easy to use. We also wanted to make it very, very easy for developers because we knew what a pain in the neck it was to have to deal, you know, to write this screen and looking up, you know, a zillion different fields and trying to figure out what the standard said about how they should be presented or what the values were. We just didn't want people to have to go through that same pain. So we tried to make it available. And I think we did a really nice job in Panther with that. We have support for a lot of different certificate formats. So, for example, PEM format certificates.

If you take a, you know, a .cer from another platform, you can double click on it and it'll be imported into your key chain. We can handle Simple PKCS 12 format. So, you know, for example, if you have an identity that you got from VeriSign or someplace like that, you can import that into the keychain. It doesn't support things like nested, you know, multiply nested PKCS 12 files, but you probably won't run into those. We also have added support for CRLs, and we have a really nice UI for dealing with user management of trust settings.

So you can say, okay, for this particular certificate that I have, I only want to trust it for SSL transactions, you know, use on a web page. Or you can say, no, I want to be able to send, sign an encrypted email with this certificate. So the user can choose those kind of things. Or they can say things like, don't ever trust this certificate. I just know that it's bad. It might say that it's good, whatever. Just don't trust it.

This is kind of a brief list of things that I mentioned that are supported in the CSP. So, you know, we really try and use AES because that is the, you know, officially supported standard by NIST. It's kind of actually amazing to me to see... 。 I'm thinking, gosh, we did this whole thing, like, the week, it wasn't even finalized yet. We already had AES in there. But anyway, we do support things like DES and triple DES because those are still around. You know, different types of keys. We support DSA and RSA public keys.

Okay, so I mentioned briefly before that disk copy uses... nd then we'll have a little bit of a look at the CDSA framework and the algorithms in there. This encrypted disk copy images are a really, really cool feature. If you don't know -- actually, let me ask, how many people know about encrypted disk copy images? Okay, good. For anybody that didn't raise their hand, you've got to learn about it. It's a very, very cool thing.

We've made it easier in Panther for users to use it and in some cases kind of made it transparent, like, for example, FileVault is underneath that. It's using a lot of the same things. an encrypted image. Even if you're not using that, you can create them from the command line or using disk utility. It's moved from the disk copy application into disk utility on Panther. But these images can be growable.

You can make them pretty small. I have one on -- I think I have one of these little devices here. This one actually has a fingerprint reader on it. So I have true three factor authentication on this. Something I have, something I know which is the password to the encrypted image that's stored on here, and something I am, which is my fingerprint. So this is cool stuff.

You can put in your PGP keys. You can put in a copy of your key chain. I don't know. It's just very useful. The other thing to note about it is that they're very high performance. So it's, I mean, you can imagine all the things that it depends on.

But just the particular test system we had set up, it took like about 10% over the CPU, or sorry, 10% over the disk speed overhead. So it was just a little bit, it was almost free, but not quite. So hopefully we'll get there at some point, make it totally free.

Just a screenshot. It's pretty much the same as making any other disk image except that there's one pop-up menu that allows you to choose the encryption method. Currently, we just support one encryption method, which is AES. But it is built on top of CDSA, so we could support different algorithms at some point.

Okay, I just want to go quickly through keychain access. Keychain has been in the OS since actually 8.6, so at this point I would imagine people are kind of familiar with it. Okay. Every user on 10, since 10.0, has had a keychain by default, and it's unlocked when you log in. One change that we've made going to Panther is that now a new user that is created will have a login keychain as opposed to just the default keychain.

Like before, we had, you know, if my account was John, my default keychain would also be named John. Now it is named login.keychain. And that allowed us to help determine which keychain people were really, really using for their login keychain. It also made it easier for people to make a second keychain in case they didn't want to have one unlocked by default.

It is a network-safe format, so it's okay to put, you know,

A couple of things that you might not know about your keychain settings, that these are good things to do. If you go into keychain access, you can set a timeout on lock, because by default, your login keychain just stays unlocked for the entire time that you're logged in. So you can set that to be five minutes, whatever. You can also set it so that it locks when it sleeps. If people have been using that feature on Jaguar, it didn't work quite the way we wanted to with closing the PowerBook and going to sleep.

So that has been fixed in a nice way, and it does the right thing. When you close it, like, for example, it'll forget the credentials for your encrypted disk copy images. So when you open the thing back up again, it's going to prompt you again. And if it doesn't get the... Either the keychain password or the disk image password, it's going to unmount the disk. So that's just the behavior you want on a portable device.

Okay. If you are in the federal space, you might be aware that we had released a product called the Federal Smart Card Package, I think in January or February, and it was available just as a... I think $49 product on the federal web store. The interesting thing is that we've rolled that functionality into Panther. It's not going to be of interest to you unless you're actually in a branch of the federal government that uses common access cards. But the thing that's sort of generally worth noting is that we have put this in.

We've done changes to, for example, screen saver, login window, things like that so that they can be used with alternate authentication methods. So there are other companies that have come out with this type of functionality, and it's worth looking at that too. I know CryptoCard has announced things, ActiveCard. Sony has come out with a fingerprint reader. So all these things are leveraged on top of the authorization API.

Okay, so at this point, I want to bring back up Eric. I want to introduce him, too, because he forgot to say who the heck he is, but he is the... John, what are you? Security Product Marketing Manager. Security Product Marketing Manager. Right, for OS X. There you go. Thanks. Is the mic on? Thanks, John.

So I saved the cool stuff for myself when putting this together. So we didn't talk a lot about what's in Panther right now, and I'm gonna go through some of those things, some of those nifty features right now. As you can see here under your Internet Connect dialog, we now have VPN support for L2TP over IPsec, yay. And that's in client and server.

Yeah, pretty excited about that. Also, we'll go in a little deeper about what we've done for 802.1X. So we also support that as well for wired and wireless networks, which is great. So a very simple-to-use screen for the user to put in their settings. Not a lot of difficulty there. Also, multiple configuration support. So this is great.

Kind of excited about this. So if you're moving around from network to network or you're traveling, you can just set up. I'm at home, I'm at the office. And however you need to connect from that point. So we support that as well. And that's also in VPN and 802.1X.

Now, you're probably familiar with the built-in firewall, but for those of you who are not, I wanted to mention it. We have a built-in firewall based on IPFW. Quite simple to use. And your users, as they enable services, the ports automatically open within the firewall themselves. Or you can customize it further for other well-known services that you'll see there, Apple Remote Desktop and what have you, or things that aren't listed.

So we give you full customization of the firewall. And also within the OS transport security, a lot of this drops down to the CDS layer and makes calls from that point. But of course, we support OpenSSL, TLS, and all of the variants of that. And then, of course, OpenSSH is built into the system.

So that kind of ends a lot of the features that are in the OS around security. We also are very concerned about holes that pop up because let's face it, they do arise. So we try to keep you as users informed about this. We also work with cert and first to receive and distribute information.

We have a mailing list that you can get hooked up to. So if any alerts come out, you can get those sent to you so you don't have to actively check yourself. In addition, we have a An email address, that's what the thing is, that you can report security rules that you may find, and we actually do take them quite seriously when we research every one we get.

And then also updates to the system, if there's any security holes or vulnerabilities that pop up, we can update those quite easily with security updates right within the system. So just to summarize some of the recommendations we have here today, controlling physical access is huge. That's paramount. I completely recommend using open password security, and it looks like a lot of you guys do here.

Use the home directories, and as you know now, that file vault is there, and you can just click a setting and your users will be secured. Use the built-in firewall. Why not? It's there. It's free. What the heck? Only turn on the services that you need. There's a no-brainer. And don't make everybody an administrator unless you have to. So I'm going to bring up Sean Geddes. Sean's going to talk about the current and future initiatives of OS X and some of the neat work we're doing around that.

So I brought all my authentication devices because I was afraid I wouldn't be able to get in here. The area of security within government, many folks may initially think, that's just government, doesn't affect me. But I think all of you, don't you all pay taxes? I'll pay, somehow you're all impacted by what our government does. What we want to do is share a little bit with, related to the OS, related to efforts that Apple's doing and external entities are doing related to our product.

So within not only our government, but within governments literally around the world, there's the need to... Evaluate to provide assurance that the product truly is providing those secure services. We're leveraging a lot of open source. How does Apple or how do others ensure to you, the customer, to integrators, to others, that that product is providing that true security out of the box and with some of the recommendations that Eric and John and Dave had mentioned a little bit earlier? So common criteria, widely known also as ISO 15408, for those of you kind of in the other part of the world, this is to address just that. How do you evaluate and how do you put a level playing field, so to speak, on evaluating the security of the products? Just to hit on some of these, it's really to address issues in the markets, international computer market trends, evaluation or evolution.

So the first thing is the evolution of adaptation of earlier criteria. If you saw the chain of events of TSX and other products, other documents, other government agencies that have involved themselves in making this a ubiquitous or a globally recognized approach. All of this feeds into providing a much larger worldview of how to look at products with respect to security. So with that, I'm going to turn it over to Eric. Thank you.

Thank you, John. So the first thing I wanted to do was to talk about the common criteria with Apple. First of all, I wanted to give a couple points to let you know really what this is doing. First of all, it's an independent, certified lab that's looking at OS X, OS X server, to validate vendor claims, validate what Apple is claiming about the product itself. So the feature set and the capabilities. Again, I had mentioned about being globally accepted. It's ISO 15408.

But what is Apple's target? What are we doing with respect to Mac OS X and Mac OS X Server? We are shooting for pretty much kind of the standard for all operating systems, and that's the controlled access protection profile. The profile is really what the functional requirements of the OS, what are those features, what's really in the product itself.

The reference at the end there is really for the assurance level. How sure are you or how sure can the independent lab provide to you that indeed that claim, that functional feature, is again tested or truly is there? And again, a level three goes through a methodically tested and checked process. There are multiple levels in this that get into a more granular kind of... providing evidence and all that.

Again, those features are indeed there. They're there. But I think for you all, you want to know what value is it going to be to you, right? What is Apple's evaluation of OS X and OS X Server for common criteria? What value add is that going to be for you? One of the key things is that, you know, we've talked a lot about that here at WWDC, the open source kernel.

When you're dealing with a security of OS X and OS X Server... you're truly looking at all of the open source code. You're looking at the kernel. You're looking at all the security frameworks that have been mentioned. So you, from the developer standpoint, are now getting, for you, an independently certified open source under the framework for the operating system. Oops, I'm going backwards. You always have to hit the right button.

Okay, for developers, not only that, but you now have a secure foundation to build your solutions on as well. Much like I mentioned about securing a foundation for OS X, since Darwin is the open source, that could now be an embedded system for other solutions that you yourself are building as well.

So some of the things that we want to move into and share with you from a perspective of what we're doing within the government space, or at least with the collaborative within that space. Kind of the second line there, security built in, not bolted on. I guess that's kind of our mantra within our space. There's so many products, so many vendors that have solutions where security is an afterthought. Hopefully you have seen that Apple is doing this right from the start.

But not only building things from the start, you have to have that evolution and carry that through with products. One of those approaches is, and I'll get into a little bit more of this later, is a secure trusted OS consortium that Eric had mentioned. This is really an open, collaborative, community-based environment for enhancing the security of Darwin. Again, you're going to have this independently certified kernel and security frameworks.

You need some additional enhancements to keep up with the times, keep up with security innovation. Again, that's the focus of Stas, and we'll get into a little bit more about that in a bit. Some other efforts that we do is we've done some work as well relating with DARPA.

DARPA is a Defense Advanced Research Project Agency, and an individual there is Doug Monn, who has been heading up one of his projects. It's called CHATS. It's Composable High Assurance Trusted Systems. The reason that's important is, as I just mentioned, Stas is focused on enhancing the security of Darwin. The focus of chats is to enhance the security of all open source operating systems. So we are kind of a spoke in that whole process.

One other thing is related to Kratus. Kratus, for those of you who don't know, is a cooperative research and development agreement. And what that does is allow two or more parties to work together in a very collaborative, very interactive way to share the technologies, to really get a little bit deeper into solutions without looking specifically at producing a product at the end of the month or the next quarter. It's real research related with experts involved.

John had mentioned the federal smart card integration that we talked about a little bit earlier. We did that specifically to address Department of Defense needs for the CAT card, which I've got a few of those here. This is yet another way that the government and Apple being involved in this as well is trying to provide another alternative for authentication, providing some mechanism for you, the user, within the OS.

And finally, those of you who are familiar with NIST, National Institute on Standard of Technology, there are many initiatives going on there that we're a part of that is key to impacting, again, not only government, but guidelines and standards for rolling out enterprise and businesses after that as well. Many groups look to the guidelines there for providing the direction.

So let's look at just some of these in a little bit more detail. I mentioned a little bit about SecureTrustOS Consortium. This is that collaboration between the public, private, and academic sectors. So there are university folks involved, there are industry folks involved, and there are government folks involved. Again, an open collaboration, all looking at the open source, addressing specific needs, working together on issues, maybe highlighting some areas that need work, and then going forth kind of both with the passion and with the need within the organizations to make that happen.

It truly becomes a collaborative sandbox because you're working through those issues, and this then becomes a staging area for X. Essentially what we're doing is we're enhancing the kernel. It rolls right into Darwin CVS that becomes the foundation for OS X. So it truly becomes a staging area for Mac OS X.

I want to give you at least some idea, both from the high end and from a low end, of the type of things that we address. One thing is, kind of maybe from a more intense area, is actually evaluating the original snapshot of Darwin at the time against other efforts, maybe even like SELinux or some of the other initiatives that have been funded and implemented in the past.

." Where does Darwin stand within that mix? What's the level of effort to bring it up to speed or up to kind of on par with those same solutions? So that was one of the efforts that had already gone on. Then there were some other ones that may seem pretty small, but they have a much bigger impact, and that was even leveraging the CDSA architecture within even just one of the modules within Apache. Well, what are we doing going forward? Some of those projects... Are security guidance documents.

I know I've been talking to several folks here at the conference, and we don't yet provide any real documentation for what do I do to really configure kind of after I get out of the box and after everything's shut down, what do I really get? Where do I go? Where do I... I see kind of a document to tell me what to do to lock this down to some agreed level of security. So that's one of the efforts moving forward.

That's kind of at the low end. And at the high end is kind of nirvana, right? The ultimate goal is this true SE Darwin, so to speak, kind of on parallel with SE Linux approach. That's the Stas effort. I mentioned CRETA. CRETA, again, is the Cooperative Research and Development Agreement. It's focused on security specifically, right? A CRETA can be anything. A CRETA can be just looking into any type of technology solving a real-world problem.

In here, let's first take a look at... what it does immediately for Apple and the partner, if that's in the situation. And then we'll look at how it impacts and affects you all as well. So first of all, when we're focusing on this, there's a big technology transfer, right? Apple does some awesome stuff internally with a security team and within managing new projects, bringing in the open source community. But when you're really trying to address security at the whole, holistically, from all angles, you really need to reach out and exchange that technology, both intelligence, the expertise, and literally down to the code level. And that's where the technology transfer comes in.

Sharing of expertise, ideas. It really is now enabling the partners to get further along than they would on their own. That's kind of a given, right? If two people are working on the problem, you're going to solve it much quicker if you're both working pretty good and sharing your resources. You're going to get the problem solved sooner than if you're both working kind of in parallel on your own solution.

So the real important thing to you is, how is Apple's involvement in Accraida going to help you? The first thing is that much like I mentioned with Stas, now you're getting the benefit of an enhanced foundation to build your solutions on, whether you build it directly on OS X, OS X server, or directly on Darwin with security frameworks. You're getting that as part of your development process literally for free.

You're getting that as part of the solution from Apple. The same thing, technology transfer. You may not have that area of expertise, maybe in encrypted storage containers like the encrypted disk copy image or public key. That may not be your expertise, but now you're getting that essentially for free from this effort.

And the real key thing is that now you can focus more on your killer application that makes you more money rather than focusing on trying to get and build in all that security from the start within your application. And the key thing is that we're all benefiting from this effort. It's not just an Apple. It's not just a partner. We're all benefiting from all this effort. John had mentioned about the smart card.

DoD has pretty much led the way on this. And what I wanted to show is a couple highlights. One thing is this is a multi-purpose ID. I think there's specifically about five very directed types of solutions that are being solved or needs being solved by the smart cards. The physical identification, the secure logging into systems, the... the signing and encrypting of mail, secure web access. And I think many of you have seen this in other sessions.

But it's a multi-purpose card, right? Multiple functions. And I've got tons of cards so you can see that it goes beyond the need for just one. But again, the key thing, the reason I want to bring this out for you all is that they already have issued 2.4 million of these just within DoD. And they're issuing 10,000 a day. That's a business opportunity.

This is where the money comes in for you all. Not only that is that as things move forward, the estimate is about another 1.3 million a year. This is only, I'm only referring at the moment to DOD. Then you have all the other agencies within the federal government. Many of you probably should have seen areas even within state local governments are looking at types of solutions like this. Again, big opportunities for you.

Those who also are in the area of biometrics within the DOD space, they're looking to incorporate that as well in with smart cards. So again, this is where you can start leveraging the technologies that are on the platform. On the right side, you're seeing a little bit of the anticipated deployment numbers. Some of those are a little bit debated by various folks, but being upwards into 2005, possible deployment of up into the 16 million card range. Again, just within our space.

Maybe at this point I guess I need to bring back Mr. Hutzler or I guess the whole team. So thank you very much for allowing me to share. So this is going to be part of your pack when you get your DVDs, so I just thought I'd put those on there for you as reference later on.