---

Security Services

Mac OS X provides several security APIs to make it easy for developers to add such features as authorization and evaluation of digital certificates to their applications. This chapter describes security features provided automatically by Mac OS X, the high-level security APIs provided by Mac OS X and shown in Figure 1-3, and user-level security features. The lower-level APIs provided by Apple’s implementation of CSSM are not described here. Those APIs are fully documented in Common Security: CDSA and CSSM, version 2 (with corrigenda), from the Open Group (http://www.opengroup.org/security/cdsa.htm).

In this section:

Restrictions On Code Execution
File Quarantine
Authentication
Authorization Services
Cryptography
Certificate, Key, and Trust Services
Code Signing
Keychain Manager and Keychain Services
Smart Card Services
Secure Transport
CFNetwork
URL Loading System
Kerberos
Security Objective-C API
Movie Toolbox Access Keys
User-Level Security Features

Restrictions On Code Execution

A common way for a hacker to gain control of a system is to exploit a buffer overflow in a running program. A buffer overflow occurs when a program does not validate its input and accepts more data than can fit in the memory that the program reserved for that data. The data then overwrites memory owned by the system or by some other program. In some circumstances, the hacker can insert executable code directly into memory this way; in other cases, the hacker can cause a jump of execution to another location in memory. For more information how such a buffer overflow is exploited, see Types of Security Vulnerabilities in Secure Coding Guide.

In order to make such exploits more difficult, starting in Mac OS X v10.4, a change was made to prevent the execution of code in the region of memory known as the stack on Intel-based Macintosh computers by default. In Mac OS X v10.5, the restrictions on executing code were extended in two ways: First, the system now disallows the execution of stack-based code on both PowerPC-based and Intel-based Macintosh computers by default. Second, for 64-bit programs, the system now disallows attempts to execute code in any portion of memory unless that portion is explicitly marked as executable. Most developers may not notice these changes because code compiled and linked statically is automatically marked as executable by the linker. A 64-bit application that generates code dynamically, however, must explicitly mark that code as executable or the program receives a SIGBUS signal and exits when trying to execute that code. A program can use the mprotect system call with the PROT_EXEC option to grant execute permissions to a block of memory containing dynamically generated code. For information on how to use this call, see the mprotect manual page.

To limit the damage in case a program is hijacked, both Mac OS X and iPhone OS provide process sandboxing (“Sandboxing and the Mandatory Acccess Control Framework”). In Mac OS X, a limited high-level sandboxing interface is provided by the command-line function sandbox_init. See the sandbox_init manual page for documentation. In iPhone OS, every application is sandboxed during installation. The application, its preferences, and its data are restricted to a unique location in the file system and no application can access another application’s preferences or data. In addition, an application running in iPhone OS can see only its own keychain items.

Because every iPhone OS application is sandboxed, your application’s data and preferences cannot be read or modified by other applications, even if they have been compromised by an attacker. If your application is compromised, the attacker cannot use it to take control of the device or to attack other applications.

File Quarantine

Starting in Mac OS X v10.5, applications that download files from the Internet or receive files from external sources (such as email attachments) can assign quarantine attributes to the file using a function in Launch Services. The attributes associate basic information with the file, such as its type, when it was received, and the URL from which it came. When the Finder or any other program uses Launch Services to open a quarantined file, Launch Services inspects the file to see if it appears to be an application, script, or other executable file type. If so, the system displays an alert informing the user that the file is an application and asking for confirmation that it should be executed. The alert lets the user open the URL from which the file was downloaded, launch the program, or cancel. If the user proceeds to open the file, Launch Services removes the quarantine attributes from that file.

If you are developing a web browser or email program, or if your software somehow deals with files from unknown sources, you should use the Quarantine feature as part of your program’s basic security procedures. Quarantine is part of the Launch Services API, which is itself part of the Core Services framework. For more information about the Quarantine feature, see Launch Services Release Notes.

Authentication

Authentication is the process of verifying the identity of a user or service. Authentication is normally done only as a step in authorization. Authentication answers the question “Is this entity who it claims to be?” before authorization asks “Does this entity have permission to perform this operation?” Therefore, Mac OS X has no separate authentication API. Some applications and operating system components carry out their own authentication; for example, see “Movie Toolbox Access Keys.” Mac OS X Authorization Services handles authentication for you when necessary (see “Authorization Services”; there is no authorization API in iPhone OS). If you are using digital certificates for authentication—for example, when you need to authenticate a web server— use the functions in Certificate, Key, and Trust Services. See “Certificate, Key, and Trust Services” for a description of that API. To exchange certificates over a secure connection, use the Secure Transport API described in “Secure Transport” (Mac OS X only) or one of the high-level APIs that call Secure Transport—see “CFNetwork” (Mac OS X or iPhone OS) or “URL Loading System” (Mac OS X only). To authenticate with a directory server, use the Open Directory API. See Open Directory Programming Guide in Networking Documentation for details.

Authorization Services

Authorization is the process by which an entity such as a user or a server gets the right to perform a restricted operation. (Authorization can also refer to the right itself, as in “Bob has the authorization to run that program.”) Authorization usually involves first authenticating the entity and then determining whether it has the appropriate permissions. See “Authorization” for more information about this process.

The principal Mac OS X API for authorization is Authorization Services. Authorization Services is implemented by the Security Server daemon (“Security Server”) and built on top of BSD. Unlike BSD, however, which can control access at the level of individual files or programs, Authorization Services lets you control access to specific features or data within an application. The security daemon uses a policy database to determine the rights of a given authenticated user. Authorization Services includes functions to read, add, edit, and delete policy database items. There is no authorization API in iPhone OS—instead, the user can set a PIN to protect the device and each application is prohibited from accessing data belonging to another application (see “Restrictions On Code Execution”).

When you request that Authorization Services authorize a user to perform a certain action, the Security Server authenticates the user if necessary. Because the interaction with the user is handled automatically for you, your code is not affected by the authentication method in use. For example, if at some time in the future Apple provides a user interface to support smart card authentication, your application will automatically gain the benefits of this new feature without any changes in your code.

Occasionally a Mac OS X application needs to perform some operation that requires running with root privileges, for example, when installing new software. In order to avoid having the entire application run as root, in this case the developer creates a separate helper tool that runs with root privileges only as long as is necessary. Applications in iPhone OS cannot run with root privileges.

To learn how to use Mac OS X Authorization Services, start with Authorization Services Programming Guide and then look at Authorization Services C Reference, both in Security Documentation. There are also technical notes, Q&As, and sample code for Authorization Services available from the Reference Library > Security page on the ADC website.

Cryptography

You can use Keychain Services to encrypt and store small amounts of data (see “Keychain Manager and Keychain Services”). In Mac OS X, if you want to encrypt or decrypt larger amounts of data, you can use the CSSM Cryptographic Services Manager (see “CDSA”). This manager also has functions to create and verify digital signatures, generate cryptographic keys, and create cryptographic hashes. To see exactly which security protocols and algorithms are supported by Apple’s Cryptographic Service Provider (CSP) implementation, see the documentation provided with the Open Source security code, which you can download at http://developer.apple.com/opensource/security/index.html. In iPhone OS, CSSM is not available, but many of these functions are provided by the Certificate, Key, and Trust Services API.

The sample code CryptoSample contains source code and program examples for a library intended to facilitate the use of the Cryptographic Services Manager, specifically for symmetric encryption and message digest calculation.

Starting with Mac OS X v10.5, you can use the Cryptographic Message Syntax Services programming interface to encrypt or add a digital signature to S/MIME messages. See Cryptographic Message Syntax Services Reference for details.

Certificate, Key, and Trust Services

Certificate, Key, and Trust Services is a C API for managing certificates, public and private keys, and trust policies. You can use these services in your application to:

• Add a certificate to a keychain

• Retrieve information from a certificate

• Convert between a binary representation of a certificate and a certificate object usable by the API

• Retrieve the certificate associated with a specific cryptographic identity

• Retrieve the private key that’s associated with a specific cryptographic identity

• Create a pair of asymmetric keys

• Retrieve the value of a trust policy

• Evaluate the trust associated with a specific certificate and trust policies

• Set anchor certificates

In Mac OS X, functions are also available to:

• Retrieve anchor certificates

• Set user-specified settings for trust policies for a given certificate (see Figure 3-3 for examples of trust settings)

In iPhone OS, additional functions are provided to:

• Use a private key to generate a digital signature for a block of data

• Use a public key to verify a signature

• Use a public key to encrypt a block of data

• Use a private key to decrypt a block of data

Certificate, Key, and Trust Services operates on certificates that conform to the X.509 ITU standard, uses the keychain for storage and retrieval of certificates and keys, and uses the trust policies provided by Apple. See the Security Release Notes for details about Apple’s certificate trust policies.

Because certificates are used by SSL and TLS for authentication, the Mac OS X Secure Transport API includes a variety of functions to manage the use of certificates and root certificates in a secure connection. See “Secure Transport” for more information about Secure Transport.

To display the contents of a certificate in a Mac OS X user interface, you can use the SFCertificatePanel and SFCertificateView classes in the Security Objective-C API. In addition, the SFCertificateTrustPanel class displays trust decisions and lets the user edit trust decisions. See “Security Objective-C API” for more information about this API.

Code Signing

Starting with Mac OS X v10.5, developers are expected to add a digital signature (“Digital Signatures”) to each Mac OS X program. Digital signatures are required on all applications for iPhone OS. In addition, Apple adds its own signature before distributing an iPhone OS application. The addition of a digital signature to an application or block of code is often referred to as code signing.

Code signing ensures the integrity of the program and allows the system to recognize updated versions as the same program as the original. Once a program is signed, any change in the code not intended by the developer—whether introduced accidently or by hackers—can be detected by the system. On the other hand, a signature on an updated version of a program tells the system to treat the new version exactly as it treated the old. On Mac OS X, this means that users are not asked to give their keychain password before the system executes the program. On iPhone, users are never asked for a password, but an application that hasn’t been signed by Apple will not execute.

Because signatures are ignored by Mac OS X versions prior to Mac OS X v10.5, signing applications does not affect whether they are backward compatible with earlier versions of the operating system. On the other hand, because Mac OS X v10.5 and later systems expect all code to be signed, any code that is not signed does not behave in the same manner as the majority of the programs on the user’s system. In particular, the user is likely to be bothered with additional dialog boxes and prompts for unsigned code that they don’t see with signed code, and unsigned code might not work as expected with some system components, such as parental controls. On iPhone OS, Apple does not sign applications that have not been signed by the developer, and applications not signed by Apple simply will not run.

The procedure for signing code is not time consuming and requires few resources. See Code Signing Guide for details.

Keychain Manager and Keychain Services

The keychain provides secure storage of passwords, keys, certificates, and notes for users. Applications can use the keychain to store and retrieve data, passwords, encryption keys, and certificates. In Mac OS X, the user is prompted for permission when an application needs to access the keychain; if the keychain is locked, the user is asked for a password to unlock it. In iPhone OS, an application can access only its own items in the keychain—the user is never asked for permission or for a password. There are two Mac OS X APIs for the keychain: Keychain Manager and Keychain Services. Only Keychain Services is available in iPhone OS.

The Keychain Manager is part of the Carbon framework and is maintained for compatibility with older versions of Mac OS X. For newer versions of Mac OS X (starting with Mac OS X v10.2), Keychain Manager functions call Keychain Services rather than calling CSSM directly. In addition, because all new API development is being done on the Keychain Services API, it is a richer and more flexible API than the Keychain Manager. Therefore, Keychain Services is the preferred API unless you are writing code to run on Mac OS X v10.1 or earlier.

Keychain Services allows you to create keychains, add, delete, and edit keychain items, and—in Mac OS X only—manage collections of keychains. In most cases, a keychain-aware application does not have to do any keychain management and only has to call a few functions to store or retrieve passwords.

Backups of iPhone OS data are stored in plaintext, with the exception of passwords and other secrets on the keychain, which remain encrypted in the backup. It is therefore important to use the keychain to store passwords and other data (such as cookies) that are used to access secure web sites, as otherwise this data might be compromised if an unauthorized person gains access to the backup data.

To get started using Keychain Services, see Keychain Services Programming Guide and Keychain Services Reference.

In Mac OS X, the Keychain Access application provides a user interface to the keychain. See “Keychain Access” for more information about this application.

Smart Card Services

A smart card is a plastic card similar in size to a credit card that has memory and a microprocessor embedded in it and is therefore capable of both storing information and processing it. For security purposes, smart cards can store passwords, certificates, and keys. A smart card normally requires a personal identification number (PIN) or biometric measurement (such as a fingerprint) as an additional security measure. Because it contains a microprocessor, a smart card can carry out its own authentication evaluation offline before releasing information. Smart cards can exchange information with a personal computer through a smart card reader.

The PC/SC Workgroup (http://www.pcscworkgroup.com/) has established a standard for accessing cards and writing card reader drivers.

Apple provides a Smart Card Services software development kit (SDK), which contains source code that you can use to implement a PC/SC-compliant application or driver. The PC/SC framework, with header files, is included in Mac OS X at /System/Library/Frameworks/PCSC.framework. Apple’s smart card support is based on the Movement for the Use of Smart Cards in a Linux Environment (MUSCLE) Open Source implementation of the PC/SC standard. The MUSCLE homepage is http://www.linuxnet.com/ and the MUSCLE PC/SC Lite API Toolkit API Reference Documentation is available at http://pcsclite.alioth.debian.org/pcsc-lite/.

The ADC Security homepage at http://developer.apple.com/security/ includes a link to the sourcecode for Apple’s Smart Card Services project, which is at http://www.opensource.apple.com/darwinsource/Current/SmartCardServices/. You must agree to the Apple Public Source License (APSL) before you can download the code. The code includes drivers and the pcscd command line tool, which launches a PC/SC smart card daemon. See the manual page for pcscd for more information on this daemon.

The preferred means to work with smart cards on Mac OS X v10.4 and later is by using Keychain Services. Mac OS X v10.4 and later implements the Tokend interface that allows smart card developers to make their cards appear to be keychains. Tokend is not yet an official API, but it is supported by DTS. DTS has a sample Tokend project and related documentation available on request. Keychain Services is documented in Keychain Manager Reference and Keychain Services Programming Guide.

Secure Transport

Secure Transport is Apple’s implementation of SSL and TLS, used to create secure connections over TCP/IP connections such as the Internet (see “Secure Communication”). In iPhone OS, there is no API for Secure Transport; use CFNetwork for secure connections. In Mac OS X, you can use the Secure Transport API to set parameters for a secure session, open and maintain a session, and close a session. Functions provided by Mac OS X Secure Transport allow you to:

• Set which SSL/TLS protocol versions are allowed

• Specify which cipher suites should be enabled for a session

• Specify whether client-side authentication should be required

• Specify certificates to be used for the session

• Specify whether expired certificates are allowed

• Specify trusted root certificates for the session

• Specify whether unknown or expired root certificates are allowed

• Specify Diffie-Hellman parameters

• Specify the domain name of the other end of the connection

• Set up and open an SSL or TLS session

• Determine which SSL/TLS protocol was negotiated for the session

• Determine which cipher suite was negotiated for the session

• Obtain the current ID data of the other end of the connection

• Read and write data in a session

• Terminate the session

To get started with Secure Transport, see Secure Transport Reference. For sample code, see SSLSample.

CFNetwork

CFNetwork is an API for creating, sending, and receiving serialized messages over a network. It is a high-level interface that can be used to set up and maintain a secure SSL or TLS networking session. CFNetwork includes the following security-related components:

• CFHTTPMessage, which you can use to create, serialize, deserialize, and manage HTTP protocol messages. This component lets you add authentication information to a message.

• CFHTTPAuthentication, which applies authentication credentials to challenged HTTP messages.

• CFStream Socket Additions, which allocates read and write streams and provides constants used with the CFReadStream and CFWriteStream APIs to set security protocols.

• CFFTPStream, which you can use to peform FTP file transfers. This component lets you send passwords to FTP servers.

In addition to the CFNetwork API, you use the CFReadStream and CFWriteStream APIs in the Core Foundation framework to create and manage the read and write streams that CFNetwork depends on. You can specify an SSL or TLS protocol version to encrypt and decrypt the data stream. Note that CFReadStream and CFWriteStream are “toll-free bridged” with their Cocoa Foundation counterparts, the classes NSInputStream and NSOutputStream. This means that each Core Foundation type is interchangeable in function or method calls with the corresponding bridged Foundation object, so you can use either C or Objective C interfaces, whichever is most convenient for you.

URL Loading System

The URL Loading System is a very high-level Mac OS X API that you can use to access the contents of HTTP://, HTTPS://, and FTP:// URLs. Because HTTPS:// websites use SSL or TLS to protect data transfers, you can use the URL Loading System as a secure transport API. See URL Loading System for information about this API.

Kerberos

Kerberos is an industry-standard protocol used to provide authentication over a network. Kerberos is highly secure, can be used for any number of users and servers on a network, and provides single-signon authentication—that is, users provide authentication credentials (such as user ID and password) only once, after which they can access additional services without reauthenticating. Mac OS X Kerberos works with all common directory servers, including LDAP (Lightweight Directory Access Protocol) servers and Microsoft Windows Active Directory servers. Mac OS X Server v10.2 and later can host Kerberos authentication services and Mac OS X v10.5 and later includes a full Kerberos implementation, so that any user’s computer can serve as either a Kerberos server or client.

Security Objective-C API

The Security Objective-C API (available only on Mac OS X) includes theSFAuthorization class, which provides an Objective-C interface for Authorization Services. The other classes in this API provide security-related UI elements, as follows:

• TheSFAuthorizationView class implements an authorization view in a window. An authorization view is a lock icon and accompanying text that indicates whether an operation can be performed (Figure 3-1). If the lock is closed, when the user clicks it, an authorization dialog displays. Once the user is authorized, the lock icon appears open. When the user clicks the open lock, Authorization Services restricts access again and changes the icon to the closed state.

  Figure 3-1  Authorization view

  

• The SFCertificateView and SFCertificatePanel classes display the contents of a certificate. The SFCertificateView class is used by the Keychain Access application, for example (Figure 3-2).

  Figure 3-2  Certificate view

  

• The SFCertificateTrustPanel class displays and optionally lets the user edit the trust settings in a certificate. Figure 3-3 shows this feature as used by the Keychain Access application.

  Figure 3-3  Editable trust settings

  

• The SFChooseIdentityPanel class displays a list of identities in the system and lets the user select one. In this context, identity refers to the combination of a private key and its associated certificate. If a user had two or more certificates, for example, each with its own private key, the user’s email application could use this interface to let the user select which identity to use to sign a specific letter.

• The SFKeychainSavePanel class adds an interface to an application that lets the user save a new keychain. The user interface is nearly identical to that used for saving a file. The difference is that this class returns a keychain in addition to a filename and lets the user specify a password for the keychain.

• The SFKeychainSettingsPanel class displays an interface that lets the user change keychain settings. Figure 3-4 shows this interface in the Keychain Access application.

  Figure 3-4  Keychain settings

  

Documentation for the Security Objective-C API is in Security Interface Framework Reference.

Movie Toolbox Access Keys

Movie Toolbox Access Keys is a QuickTime API that provides password protection to QuickTime data. You can add password protection to a QuickTime movie—so that only users who know the password can run the movie— or you can add password protection to data, so that only an application that has registered that access key can get access to the data.

For documentation on Movie Toolbox Access Keys, see Movie Toolbox Access Keys in QuickTime Movie Internals Guide.

User-Level Security Features

There are many security features built into Mac OS X and iPhone OS, including industry-standard digital signatures and encryption for Apple’s Mail application and authentication for the Safari web browser. The four features most visible to users of Mac OS X are:

• Security system preferences

• File Vault, which users can configure through Security system preferences

• Accounts system preferences

• the Keychain Access application

Security System Preferences

Security system preferences in Mac OS X let the user configure FileVault (discussed next) and control some aspects of authorization on the computer (Figure 3-5).

The Security system preferences dialog lets the user specify whether authorization should be required:

• To wake the computer from sleep or a screen saver

• For every account on login

• To unlock each lockable system preference

At the bottom of the dialog is the lock icon provided by the authorization view (see “Security Objective-C API”). When this icon shows a closed lock, authorization is required before the user can change the settings in this system preferences dialog.

FileVault

When the user turns on the FileVault operating system feature (see Figure 3-5), Mac OS X uses 128-bit AES encryption to encrypt everything in the user’s home folder. As long as the user is authenticated and logged in, the system automatically unencrypts any file the user opens. However, no other user can gain access to these files.

AES (Advanced Encryption Standard) is a symmetric-key algorithm adopted by the National Institute of Standards and Technology (NIST) as a standard for government and private use to protect sensitive, nonclassified data. It enables very fast and highly secure encryption and decryption of data. Because it is a symmetric-key algorithm, keys are stored securely on the user’s computer.

Full documentation of the AES algorithm is available on the NIST website at http://csrc.nist.gov/CryptoToolkit/aes/rijndael/.

Accounts System Preferences

When a user installs Mac OS X on a computer, that user automatically becomes a member of the admin group (“The Admin Group”). Subsequently, the user or any other member of the admin group can use Accounts system preferences to add new users to the system.

For each new user, the administrator can specify whether that user is a member of the admin group (Figure 3-6). If a FileVault master password has been set, the administrator can also turn on FileVault for the new account.

If the new user is not a member of the admin group, the administrator can limit the system features and applications to which that user has access (Figure 3-7).

Keychain Access

Keychain Access is a Mac OS X utility that gives users access to Keychain Services (“Keychain Manager and Keychain Services”). A user can see the passwords, certificates, and other data that are stored in their keychain. They can create new keychains, add and delete keychain items, lock and unlock keychains, and select one keychain to be the default.

Keychain access lets the user see what certificates are available for use by email and web applications, who owns each certificate, and who issued each certificate. Certificates are described in “Digital Certificates.”

The user can see and change passwords stored for various applications and can securely store other secrets such as passwords, credit card numbers, and notes. When a keychain is locked and an application needs to gain access to a keychain item, Keychain Services prompts the user for a password.

In addition, the Keychain Access menu includes items to open the Certificate Assistant and Kerberos Ticket Viewer utilities. The Certificate Assistant enables users to create certificates, request certificates from a certificate authority, create a public/private key pair, or evaluate a certificate. The Kerberos Ticket Viewer lets users see any Kerberos tickets in use on the system, and enables them to renew or destroy a ticket as well as change a ticket’s password.

---