---

Security Architecture

This chapter describes the components of security services on Mac OS X (in the following section) and iPhone OS (see “iPhone OS”). For each platform, the available security APIs are briefly described as well. For more extensive descriptions of the security APIs in each platform, see “Security Services.”

In this section:

Mac OS X
iPhone OS

Mac OS X

Mac OS X security services are built on two open-source standards: BSD (Berkeley Software Distribution) and CDSA (Common Data Security Architecture). BSD is a form of the UNIX operating system and provides fundamental services, such as the basis for the Mac OS X file system, including file access permissions. CDSA provides a much wider array of security services, including finer-grained access permissions, authentication of users’ identities, encryption, and secure data storage. Although CDSA has its own standard application programming interface (API), it is complex and does not follow standard Macintosh programming conventions. Therefore, Mac OS X includes its own security APIs that call the CDSA API for you.

The Mac OS X security architecture is layered, with BSD on the bottom, CDSA in the middle, Mac OS X security APIs above that, and applications that call the security services at the top. Figure 1-1 illustrates this architecture.

BSD and Mach

The Mac OS X kernel—the heart of the operating system—is built from BSD and Mach. Among other things, BSD provides basic file system and networking services and implements a user and group identification scheme. BSD enforces access restrictions to files and system resources based on the user and group IDs. Mach provides memory management, thread control, hardware abstraction, and interprocess communication. Mach enforces access by controlling which tasks can send a message to a given Mach port, where a Mach port represents a task or some other Mach resource (see “Mach Port Rights” for a discussion of Mach ports). BSD and Mach are both critical to enforcing local security; if you can break the security provided by one, you can break the other as well.

BSD security policies and Mach access permissions constitute an essential part of security in Mac OS X, but fall far short of all the capabilities that are needed. For example, although BSD can restrict access to a file to a particular user ID, it provides no facility for checking passwords or otherwise verifying that the person or process using that ID is who they claim to be. Similarly, once Mach has given the rights to one task to control another, it cannot restrict the data or features the controlling task can access.

It’s important to note that BSD and Mach access permissions are enforced by the operating system and therefore affect every process running in Mac OS X. In contrast, application-defined security policies must be enforced by those applications. The Mac OS X security APIs discussed in this document are available for that purpose.

For more information about the roles BSD and Mach play in Mac OS X, see Mac OS X Technology Overview. For a more detailed description of Mach and BSD access permissions, see “Mach Port Rights” and “BSD.”

CDSA

CDSA is an Open Source security architecture adopted as a technical standard by the Open Group (http://www.opengroup.org/security/cdsa.htm). Apple has developed its own Open Source implementation of CDSA, available as part of Darwin at http://developer.apple.com/darwin/projects/security/. The core of CDSA is CSSM (Common Security Services Manager), a set of Open Source code modules that implement a public application programming interface called the CSSM API. CSSM provides APIs for cryptographic services (such as creation of cryptographic keys, encryption and decryption of data), certificate services (such as creation of digital certificates, reading and evaluation of digital certificates), secure storage of data, and other security services (see “Apple CDSA Plug-ins” for a more complete list).

CSSM also defines an interface for plug-ins that implement security services for a particular operating system and hardware environment. The implementation on a given platform can optionally supply a middleware layer that provides an operating-system-specific API for applications. Whether such a layer is present or not, applications can call the CSSM API directly.

Mac OS X implements nearly all the standard features of CSSM, plus a set of middleware security services to provide a Mac OS X-standard interface for application programmers. In addition, to enhance the security of the most sensitive operations, the Mac OS X implementation runs a Security Server daemon as a separate process. The Security Server daemon launches another process, the Security Agent, which serves as the user interface for Security Server.

Figure 1-2 illustrates the Mac OS X implementation of CDSA. The CDSA standard defines a four-layer architecture, with the top layer being the applications that use the CDSA security features. Figure 1-2 shows the first three layers: the CDSA plug-ins, CSSM, and the Mac OS X security APIs, which constitute the middleware layer referred to in the specification. The Mac OS X Authorization Services API, the Security Server daemon, and the Security Agent shown in the figure are technically outside of CDSA, but they are shown here for completeness because they constitute an integral part of the Mac OS X security architecture.

Security contexts (see Figure 1-2) are data structures used by CSSM to assist applications in managing the many parameters used in security operations. The CSSM managers implement the standard CSSM API. (A fifth manager defined in the CDSA standard, called the Authorization Computation Services Manager, is not implemented in Mac OS X. Instead of using a CSSM API, Mac OS X Authorization Services calls the Security Server daemon directly.)

The CDSA plug-ins shown in Figure 1-2 are those provided as part of Mac OS X. The CDSA specification allows any number of plug-ins. As long as a plug-in follows the rules for interfacing with the CSSM managers, it can implement any portion of the CDSA feature set, including a combination of features associated with two or more of the CSSM managers. (See “AppleCSP/DL Module” for an example of a multiservice CDSA plug-in.) The CDSA specification even allows for the expansion of CDSA by the addition of elective module managers and associated plug-ins. Plug-ins can call each other as well as being called by the CSSM managers—in fact, it is common for them to do so.

For an introduction to CDSA, see CDSA Explained, second edition, from the Open Group. The CDSA/CSSM technical standard is Common Security: CDSA and CSSM, version 2 (with corrigenda), also from the Open Group.

As long as you use the Mac OS X security APIs, you don’t have to worry about the details of the Mac OS X CDSA implementation. However, because a call to the CSSM API allows you to specify the plug-in module to which you want to direct your request, if you want to call CSSM directly you should have some understanding of the Mac OS X CDSA plug-ins.

Apple CDSA Plug-ins

The Mac OS X implementation of CDSA includes five CDSA plug-ins (see Figure 1-2):

• AppleCSP cryptographic service provider

• AppleFileDL data storage library

• AppleCSP/DL encrypted data storage provider

• AppleX509CL certificate library

• AppleX509TP trust policy library

This section briefly describes the purpose and function of each of these modules. (See “Glossary” for explanations of any unfamiliar terms.)

AppleCSP Module

All secure communications and authentication protocols are based on keys and encryption. The Apple cryptographic service provider (AppleCSP) is a basic plug-in module used by several of the security services for creating cryptographic keys and encrypting or decrypting data. Digital signatures also use the AppleCSP module to create message digests used to create and verify the signature. A CSP can use any number of algorithms.

AppleFileDL Module

A data storage library (DL) module provides persistent secure storage; that is, storage of encrypted data on disk or another medium that persists when the power is turned off. The CDSA standard allows a DL module to use any sort of database or other data store. Keeping things simple, the AppleFileDL module stores its data in files in the Mac OS X file system. It provides lower-level services used by the AppleCSP/DL plug-in for storing secrets on the keychain, Apple’s database used to store encrypted passwords, private keys, and other secrets.

AppleCSP/DL Module

The AppleCSP/DL plug-in is a multifunction module that combines cryptographic service and data storage functions to implement the Apple keychain, used for storage of passwords, keys, and other secrets. The AppleCSP/DL module calls the AppleFileDL module to perform file I/O, and the Security Server daemon to encrypt and decrypt secrets.

AppleX509CL Module

A certificate library (CL) module performs operations on digital certificates. Digital certificates are used to establish or confirm the identity of an entity such as a website or the sender of a digitally signed message. They do so by using a digital signature to ensure that only the identified entity could have provided the certificate (see “Digital Certificates”). A CL module performs such functions as creating new certificates (in memory), creating certificate revocation lists (that indicate which certificates are no longer valid), verifying the digital signature contained in a certificate, and extracting information from a certificate. CL modules do not store persistent copies of certificates. Rather, a DL module is used for that purpose.

The AppleX509CL plug-in performs these functions for certificates that conform to the X.509 standard promulgated by the International Telecommunication Union (ITU). The X.509 ITU standard is widely used on the Internet and throughout the information technology industry for designing secure applications based on a public key infrastructure (the set of hardware, software, people, policies, and procedures needed to create and manage digital certificates that are based on public key cryptography). See “Asymmetric Keys” for more information on public keys.

AppleX509TP Module

A digital certificate has a level of trust associated with it, based on attributes of the certificate. A trust policy is a set of rules that specify the actions that can be taken given a specific level of trust. In other words, the purpose of establishing a level of trust for a certificate is to answer the question “Should I trust this certificate for this action?”

The issuer of a digital certificate adds a digital signature to the certificate to ensure that the certificate has not been altered and to verify the identity of the issuer. In general, a digital signature is verified through the use of another certificate. Consequently, each certificate is typically part of a chain of certificates that ends with a root certificate, which can be verified without recourse to another certificate (see “Digital Certificates”).

A trust policy (TP) plug-in performs two main functions: it assembles the chain of certificates needed to verify a given certificate, and it determines the level of trust that can be accorded the certificate.

The AppleX509TP module performs these functions on X.509 certificates, using trust policies established by Apple.

Security Server Daemon

The Mac OS X security implementation includes a daemon, called the Security Server, and a separate process, called the Security Agent, that is used by the Security Server for a user interface. This section briefly describes their roles.

Security Server

The Security Server is a daemon running in Mac OS X that implements several security protocols, such as encryption, decryption, and authorization computation. The use of the Security Server to perform actions with cryptographic keys enables the security implementation to maintain the keys in a separate address space from the client application, keeping them more secure. The Security Server also provides an interface in which developers use references to keys rather than using the keys directly. With this architecture, if Apple introduces a new technology, such as security smart cards, existing applications that use the Mac OS X security APIs automatically work with it.

Because Authorization Services performs functions not provided by the CDSA specification, the Authorization Services API interfaces directly with the Security Server rather than going through CDSA. The Security Server hosts authorization plug-ins that it can load as needed. This feature, like the use of key references, makes it possible to add new technologies without requiring applications to modify their code. In fact, because the Security Server handles its own communication with the user (through the Security Agent), application developers don’t have to worry about writing new user interface code to support new authentication technologies, such as fingerprint readers or iris scanners.

The Security Server has no public API. Instead, Authorization Services communicates directly with the Security Server and Keychain Services communicates with it indirectly (through the AppleCSP/DL plug-in module). In turn, the Security Server calls the AppleCSP plug-in module to perform cryptography. The Security Server uses the Security Agent to communicate with the user through dialogs and other user interface elements.

Security Agent

The Security Agent is a separate process that deals with all of the security-related user interface for the Security Server. For example, when the Security Server requires the user to authenticate, the Security Agent opens a dialog requesting a user name and password. If Apple introduced an authentication smart card reader for Macintosh computers, a new Security Server plug-in and modifications to the Security Agent would enable the Security Agent to prompt the user to insert their card instead of entering their user name and password. The application developer would not have to do a thing to get this new behavior.

The Security Agent runs with restricted permissions so that the user must be physically present, using the graphical user interface, in order to be authenticated. The graphical user interface elements can’t be used through a command-line interface such as the Terminal application or a secure shell (ssh) remote session. This restriction makes it much more difficult for a malicious user to breach an application’s security.

CSSM Services

Although the Mac OS X security APIs provide all the capabilities you are ever likely to need for developing secure applications, nearly all the standard CSSM APIs are also available for your use. This section briefly describes the functions provided by each CSSM service. For details, see Common Security: CDSA and CSSM, version 2 (with corrigenda), from the Open Group (http://www.opengroup.org/security/cdsa.htm).

Cryptographic Services

Cryptographic Services in CSSM provides functions to perform the following tasks:

• Encrypting and decrypting text and data

• Creating and verifying digital signatures

• Creating a cryptographic hash (used for message digests and other purposes)

• Generating symmetric and asymmetric pairs of cryptographic keys

• Generating pseudorandom numbers

• Controlling access to the CSP for creation of keys

To see exactly which security protocols and algorithms are supported by Apple’s CSP implementation, see the documentation provided with the Open Source security code, which you can download at http://developer.apple.com/darwin/projects/security/, and the Security Release Notes in the latest Xcode Tools from Apple.

Data Store Services

CSSM Data Store Services provides an API for storing and retrieving data that is independent of the type of storage used. If there is more than one DL module installed, the caller can query Data Store Services to learn the capabilities of each and select which one to use in a particular call. The Apple implementation of Data Store Services supports any standard CDSA DL plug-in module. The AppleFileDL Data Storage Library and AppleCSP/DL Encrypted Data Storage module both implement functions called by Data Store Services.

Certificate Services

Certificate Services as specified by CDSA performs the following functions:

• Verifies the signatures on certificates and certificate revocation lists

• Creates certificates and certificate revocation lists

• Signs certificates and certificate revocation lists

• Extracts values of fields from certificates and certificate revocation lists

• Searches certificate revocation lists for specified certificates

Apple’s implementation of Certificate Services supports all of the CL API functions in the CDSA/CSSM specification.

Trust Policy Services

The Mac OS X implementation of CSSM Trust Policy Services provides functions to verify certificates, to determine what attributes they contain and therefore the level of trust they can be given, and to construct a chain of related certificates. It does not implement other trust policy functions in the CSSM standard. Documentation for the CSSM trust policy functions supported by Apple’s TP implementation can be found with the Open Source security code, which you can download at http://developer.apple.com/darwin/projects/security/.

Authorization Computation Services

Apple’s implementation of CSSM does not include the Authorization Computation Services defined in the CDSA standard. Instead, the Authorization Services API calls the Security Server daemon directly (see Figure 1-2).

Mac OS X Security APIs

In the context of CDSA, the Mac OS X security APIs constitute a middleware layer between the CSSM APIs and applications that use CDSA (Figure 1-3). This section discusses how each of the Mac OS X security APIs fits into the overall security architecture. See “Security Services” for a more detailed description of each API.

Keychains

The keychain is used to store passwords, keys, certificates, and other secrets. Its implementation therefore requires both cryptographic functions (to encrypt and decrypt secrets) and data storage functions (to store the secrets and related data in files). To achieve these aims, Keychain Services calls the CSSM API, which calls the AppleCSP/DL CDSA plug-in module. The AppleCSP/DL module in turn calls the AppleFileDL module to perform file I/O, and the Security Server daemon to encrypt and decrypt secrets.

Keychain Manager is maintained only for compatibility with older versions of Mac OS X (v10.1 and earlier). For newer versions of Mac OS X (starting with Mac OS X v10.2), Keychain Manager calls Keychain Services rather than calling CSSM directly. Because Keychain Services is more efficient and offers more features than Keychain Manager, any new code should be written to use Keychain Services. For more information on the differences between these two APIs, see “Keychain Manager and Keychain Services.”

Secure Transport

Secure Transport is used to implement the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols, which provide secure communications over a TCP/IP connection such as the Internet. These protocols use encryption and certificate exchange to prevent eavesdropping and message tampering. Secure Transport calls CSSM to manage certificates and keys and to encrypt and decrypt data.

CFNetwork

CFNetwork is an API that provides network services. It provides a higher-level interface than Secure Transport that can be used by applications to create and maintain secure data streams and to add authentication information to a message. CFNetwork calls Secure Transport to set up a secure connection.

URL Loading System

URL Loading System is another high-level transport API. In contrast to CFNetwork, it is used to access the contents of URLs rather than to maintain a data stream. Because URL Loading System works with secure https:// URLs, it can be used for secure transport of data. URL Loading System is built on top of CFNetwork.

Certificate, Key, and Trust Services

The Certificate, Key, and Trust Services API includes functions to:

• Create, manage, and read certificates

• Add certificates to a keychain

• Create encryption keys

• Manage trust policies

To carry out all these services, the API calls a variety of CSSM functions, ultimately using the services of all of the CSSM managers discussed in “CSSM Services.”

Authorization Services

Authorization Services gives applications control over access to specific operations within the application. For example, a directory application that can be started by any user can use Authorization Services to restrict access for modifying directory items to administrators. In contrast, BSD provides access permission only to an entire file or application. Authentication Services calls the Security Server daemon directly. In turn, the Security Server calls specific CDSA plug-ins as needed.

Security Objective-C API

The Security Objective-C API is provided for the convenience of Cocoa programmers. It provides a set of Objective-C methods that are wrappers for the Authentication Services functions. In addition, it provides classes that display security-related UI elements, such as the contents of certificates, interfaces to create keychains and change keychain settings, and others. Depending on the class in use, this API calls Authorization Services; Certificate, Key, and Trust Services; or Keychain Services.

Movie Toolbox Access Keys

Movie Toolbox Access Keys is a QuickTime API that can be used to add password protection to QuickTime data. QuickTime implements its own mechanism for storing and verifying passwords. QuickTime does not call Authorization Services or any CSSM functions.

iPhone OS

Figure 1-4 illustrates the architecture of the iPhone OS and shows the location of the security services. The iPhone OS security APIs are located in the Core Services layer of the operating system and are based on services in the Core OS (kernel) layer of the operating system. Applications on the iPhone call the security services APIs directly rather than going through the Cocoa Touch or Media layers. Networking applications can also access secure networking functions through the CFNetwork API, which is also located in the Core Services layer.

Security Server Daemon

The iPhone OS security implementation includes a daemon called the Security Server that implements several security protocols, such as access to keychain items and root certificate trust management.

The Security Server has no public API. Instead, applications use the Keychain Services API and the Certificate, Key, and Trust services API, which in turn communicate with the Security Server. Because, unlike the Mac OS X security services, the iPhone OS security services do not provide an authentication interface, there is no need for the Security Server to have a user interface.

iPhone OS Security APIs

The iPhone OS security APIs are based on services in the Core Services layer, including the Common Crypto library in the libSystem dynamic library (Figure 1-5). This section discusses how each of the iPhone OS security APIs fits into the overall security architecture. See “Security Services” for a more detailed description of each API. For more information about the Common Crypto library, see the manual page for CC_crypto(3cc) in iPhone OS Manual Pages.

Keychain

The keychain is used to store passwords, keys, certificates, and other secrets. Its implementation therefore requires both cryptographic functions (to encrypt and decrypt secrets) and data storage functions (to store the secrets and related data in files). To achieve these aims, Keychain Services calls the Common Crypto dynamic library.

CFNetwork

CFNetwork is a high-level API that can be used by applications to create and maintain secure data streams and to add authentication information to a message. CFNetwork calls underlying security services to set up a secure connection.

Certificate, Key, and Trust Services

The Certificate, Key, and Trust Services API includes functions to:

• Create, manage, and read certificates

• Add certificates to a keychain

• Create encryption keys

• Encrypt and decrypt data

• Sign data and verify signatures

• Manage trust policies

To carry out all these services, the API calls the Common Crypto dynamic library and other Core OS–level services.

Randomization Services

Randomization Services provides cryptographically secure pseudorandom numbers. Pseudorandom numbers are generated by a computer algorithm (and are therefore not truly random), but the algorithm is not discernible from the sequence. To generate these numbers, Randomization Services calls a random-number generator in the Core OS layer.

---