< Previous PageNext Page >

Hide TOC

Mac OS X and iPhone OS Security Services

This article provides a brief introduction to the high-level security application programming interfaces (APIs) and user features provided by Mac OS X and iPhone OS. For more information on these features, see Security Overview.

Authentication

Authentication is the process of verifying the identity of a user or service. Authentication is normally done only as a step in authorization, which is the process of granting an entity permission to perform a particular operation. If you use the Mac OS X Authorization Services API, it handles authentication for you when necessary. Because Authorization Services implements all available authentication methods, using this API means you don't have to worry about implementing new authentication services (smart cards, biometric readers, and so forth) when they become available—your users get them automatically.

In iPhone OS, the user can set a four-digit personal identification number (PIN) to prevent unauthorized use of the device. Therefore the user of the device is presumed to be authorized to do so. In addition, each application is digitally signed and can therefore be authenticated by the operating system. Therefore, there are no authentication or authorization APIs in iPhone OS.

Because authentication requires the handling of secret information (such as a user's password), it can be difficult to write secure authentication code. Authorization Services handles the authentication interaction with the user, thus relieving you of this responsibility. See Authorization Services C Reference and Authorization Services Programming Guide for details.

Authentication is often necessary over a network—for example, to determine whether it is safe to send credit card information to a specific website. Digital certificates are often used for this purpose. The Mac OS X and iPhone OS APIs for handling digital certificates are described in Certificate, Key, and Trust Services Reference and Certificate, Key, and Trust Services Programming Guide. To exchange certificates over a secure connection, use the Secure Transport API (see Secure Transport Reference) or one of the high-level APIs that call Secure Transport—see CFNetwork Programming Guide or URL Loading System. To authenticate with a directory server, use the Open Directory API (see Open Directory Programming Guide).

Authorization

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.

The principal Mac OS X API for authorization is Authorization Services. (As discussed in “Authentication,” iPhone OS does not provide this API.) Authorization Services is built on top of BSD. Unlike BSD, however, which can control access at the level of individual files or programs, Authorization Services lets you determine whether an entity should have access to specific features or data within your application. Authorization Services 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. Modifying the policy database requires administrator access; if an application is not running with sufficient privileges, the user is prompted to authenticate as an administrator before the database is altered.

It is important to understand that Authorization Services does not enforce access controls. All that this API can do is to let you know whether the user is authenticated and whether they have permission to carry out the action they wish to perform. It is up to your program to either deny the action or carry it out.

In iPhone OS, on the other hand, each application is granted access permissions for its own files and certain system services when it’s signed by Apple, Inc. When installed on a device, the iPhone OS operating system enforces these permissions.

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 you should create a separate helper tool that runs with root privileges only as long as is necessary. See Authorization Services Programming Guide and the BetterAuthorizationSample sample code for more information on creating such a tool.

To learn how to use Authorization Services, start with Authorization Services Programming Guide and then look at Authorization Services C Reference. 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

Authorization Services, Certificate, Key, and Trust Services, file access controls, and other access and authorization services can only serve to protect data if the attacker is working remotely (over a network) or has only a short time to act. Given physical access to the computer and plenty of time, an attacker can defeat or bypass any authorization method or access controls. In this case, the only way to protect your data is through encryption.

You can use Keychain Services to encrypt and store small amounts of data (see Keychain Services Reference and Keychain Services Programming Guide). If you want to encrypt or decrypt larger amounts of data in Mac OS X, you can use the Common Security Services Manager (CSSM) Cryptographic Services Manager. This manager also has functions to create and verify digital signatures, generate cryptographic keys, and create cryptographic hashes. In iPhone OS, the Certificate, Key, and Trust Services API provides functions for generating encryption keys, creating and verifying digital signatures, and encrypting blocks of data; see Certificate, Key, and Trust Services Reference. For Mac OS X, to see exactly which security protocols and algorithms are supported by Apple’s Cryptographic Service Provider (CSP) implementation, see Apple Cryptographic Service Provider Functional Specification.

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.

The lower-level APIs provided by Apple’s implementation of CSSM are fully documented in Common Security: CDSA and CSSM, version 2 (with corrigenda), from the Open Group (http://www.opengroup.org/security/cdsa.htm).

Certificates

Mac OS X and iPhone OS include APIs to read and evaluate digital certificates that conform to the X.509 standard. Among other things, an X.509 digital certificate includes a digital signature that can be used to ensure that the certificate has not been altered and to indicate the identity of the issuer, and a public key that can be used to encrypt data so that it can be read only by the holder of the certificate. Each digital certificate also contains certificate extensions), which establish a level of trust for the certificate. Mac OS X includes several trust policies, where a trust policy is a set of rules that specify the appropriate uses for a certificate that has a specific level of trust. In other words, the level of trust for a certificate is used to answer the question “Should I trust this certificate for this action?” See Apple Trust Policy Module Functional Specification for information about the trust policies included with Mac OS X. The iPhone OS trust policies are available through specific functions in Certificate, Key, and Trust Services. For more details about the contents and uses of digital certificates, see Security Overview. For more information about policy functions in Certificate, Key, and Trust Services, see Certificate, Key, and Trust Services Reference.

Certificate, Key, and Trust Services is a C API for managing certificates, public and private keys, and trust policies. Certificate, Key, and Trust Services uses the keychain for storage and retrieval of certificates and keys, and uses the trust policies provided by Apple.

Because certificates are used by secure networking protocols for authentication, the Secure Transport API includes a variety of functions to manage the use of certificates and root certificates in a secure connection. See Secure Transport Reference 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 Interface Framework API. In addition, the SFCertificateTrustPanel class displays trust decisions and lets the user edit trust decisions. See Security Interface Framework Reference for more information about this API.

If the users of your software are not security experts or computer professionals, they probably do not know much about the purpose and use of digital certificates. Therefore, you should take care to make your user interface as clear and explicit as possible if you detect a problem with a certificate. Explain the problem in simple language and give the user as much guidance as possible in choosing how to proceed. For example, if a certificate cannot be verified because the root certificate used to verify the digital signature is not included in the root certificate database, you can offer to display the root certificate and give the user the option of adding it to the list of recognized root certificates. However, you should explain that this is a dangerous thing to do unless the user is very confident of the authenticity and trustworthiness of that certificate.

Keychain

Many applications and websites require a username and password, and it is bad security practice to use the same password for everything. On the other hand, few users can remember a large number of unique passwords and writing them down is also a risk. Mac OS X and iPhone OS solve this problem by providing secure, encrypted storage for passwords and other secrets in a password-protected database called the keychain. The keychain is also used to store certificates, which are not encrypted by the keychain, but which contain encryption keys and encrypted data. Applications can use Keychain Services to store, retrieve, and read keychain items, and Certificate, Key, and Trust Services to store and retrieve certificates and keys. In iPhone OS, Keychain Services checks an application’s signature before giving it access to a keychain, and lets an application have access only to its own keychain items (with the possible exception of items for which the application has obtained persistent references). In Mac OS X, Keychain Services displays an authorization dialog when permission is needed from the user to open a keychain or access a secret keychain item. The user can unlock a keychain with a single password, and applications can then use that keychain to store and retrieve data. Users can use the Keychain Access utility for the same purpose. In iPhone OS, the user is never asked to authenticate and no Keychain Access utility is provided by Apple.

Note that the keychain is designed to protect a user's secrets from others. Because the user has access to all secrets in the keychain, it is not useful for protecting a vendor's secrets from the user.

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 keychain items. By default, Keychain Services automatically interacts with the user to unlock a keychain when necessary in Mac OS X. In iPhone OS, the operating system handles keychain access without user interaction. Because the user can create multiple keychains in Mac OS X and can specify which one is the default keychain, you should not make any assumptions about which keychain to write to or to search. The default keychain may or may not be the login keychain. Always use the default keychain unless you have a specific reason to do otherwise.

Passwords, private keys, and other secrets are encrypted on the keychain. In Mac OS X, the user provides a password that is used to encrypt and decrypt these items. In iPhone OS, the system generates its own password and uses it to give an application access to its own keychain items. When the user backs up iPhone OS data, the data is stored in plaintext on the computer, with the exception of the encrypted keychain data, which remains encrypted. Therefore, to prevent possible compromise of secrets in backup data, it is very important for iPhone OS applications to always use the keychain to store passwords and other sensitive data.

To get started using Keychain Services, see Keychain Services Programming Guide (Mac OS X only) and Keychain Services Reference.

Smart Cards

Because passwords are often insecure—either because the user selects one that's easy to guess or because they are stored insecurely—some businesses and government agencies are starting to use smart cards for authentication. 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 an attacker needs both the physical card and the PIN, neither stealing the card nor guessing or finding the PIN alone is enough to compromise security. 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.

If you use Authorization Services to authenticate users, you don't have to do anything extra to support smart cards—Authorization Services handles interaction with the user and the interface with the card for you. If you want to provide your own smart card, see the description of Apple's smart card project on the ADC Security home page at http://developer.apple.com/security/. That page includes a link to Apple’s Smart Card Services SDK code. You must agree to the Apple Public Source License (APSL) before you can download the code. The PC/SC Workgroup (http://www.pcscworkgroup.com/) has established a standard for accessing cards and writing card reader drivers. Apple is a core member of the PC/SC Workgroup.

Secure Communication

One important aspect of computer security is the secure communication of data over a network. Mac OS X and iPhone OS use the SSL and TLS protocols and provide the Secure Transport (Mac OS X only), CFNetwork, and URL Loading System APIs for secure communication. No network should be considered to be secure without the use of a secure networking protocol. Even if you are using an internal network with no connections to the Internet, you need to use secure communication protocols and encryption to protect critical data. In a 2005 security survey by CSO magazine (in cooperation with the U.S. Secret Service and Carnegie Mellon University Software Engineering Institute's CERT Coordination Center), 23% of respondents said current or former employees were the greatest cyber security threat. Because 21% of the companies surveyed weren't sure who was the greatest threat, the real number may be higher. Software to intercept network communication packets is readily available. It's not paranoia to think that one of your employees might be trying to steal secrets over your internal network.

Secure Transport

iPhone OS Note: The Secure Transport programming interface is not available in iPhone OS. Use the CFNetwork programming interface instead.

Secure Transport is Apple’s implementation of SSL and TLS, used to create secure connections over TCP/IP connections such as the Internet. You can use the Secure Transport API to set parameters for a secure session, open and maintain a session, and close a session.

SSL and TLS use certificate-based authentication (see “Certificates”) to ensure that you are communicating with a valid server, they validate data to prevent tampering, and they can use public-key cryptography to guard against eavesdropping or message forgery. SSL is built into all major browsers and web servers (the most recent versions also include TLS). Whenever you use a secure website—for example, to send your credit card number to a vendor over the Internet—and see a protocol identifier of https rather than http at the beginning of the URL—you are using SSL or TLS for communication.

Although the TLS protocol is not interoperable with SSL, Secure Transport switches to SSL 3.0 if it cannot negotiate a TLS session with the other end of the connection.

Secure Transport has no transport-layer dependencies; it can be used with BSD sockets, Open Transport, or any other transport-layer protocol available.

To get started with Secure Transport, see Secure Transport Reference. For sample code, see SSLSample. For more information on the SSL standard, see http://wp.netscape.com/eng/ssl3/ and for the TLS standard, see http://www.ietf.org/html.charters/tls-charter.html.

CFNetwork

CFNetwork is an API for creating, sending, and receiving serialized messages over a network. CFNetwork can be used to set up and maintain a secure SSL or TLS networking session. It lets you add authentication information to a message and specify an SSL or TLS protocol version to encrypt and decrypt the data stream. For more information about the CFNetwork API, see CFNetwork Programming Guide. For more complete support for SSL and TLS, use Secure Transport.

URL Loading System

The URL Loading System is a high-level 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.

Security Interface Framework

iPhone OS Note: The Security Interface Framework is not available in iPhone OS. In iPhone OS, applications are restricted in their use of the keychain, and it is not necessary for the user to create a new keychain or change keychain settings.

One way to avoid adding security vulnerabilities to your code is to use Apple's security APIs whenever possible. The Security Interface Framework API provides 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. When the user clicks a closed lock icon, 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.
The SFCertificateView and SFCertificatePanel classes display the contents of a certificate.
The SFCertificateTrustPanel class displays and optionally lets the user edit the trust settings in a certificate.
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.)
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.

Documentation for the Security Interface framework 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 view 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. This API is not available in iPhone OS.

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. In iPhone OS, these features are largely invisible to the user, as security is handled by the system without the user’s intervention. in Mac OS X, the four features most visible to users are:

Security system preferences
FileVault, which users can configure through Security system preferences
Accounts system preferences
The Keychain Access application

Security System Preferences

Security system preferences let the user configure FileVault (discussed next) and control some aspects of authorization on the computer, such as whether the user is automatically logged in on startup and whether a password is needed to wake from sleep. The default settings tend to be chosen more for user convenience than for security. If your code handles secure data, you should encourage your users to select more secure settings for these preferences.

At the bottom of the dialog is the lock icon provided by the authorization view (see “Security Interface Framework”). 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 FileVault, Mac OS X uses 128-bit AES encryption to encrypt everything in the user’s home folder. The 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.

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. This option provides maximum security for a user's files if all sensitive data is stored in the user's home directory, if automatic login is disabled, and if a password is required to wake from sleep or from the screen saver. If a user wants to securely store files somewhere other than their home directory (such as on an external hard disk or removable media), they can create an encrypted disk image.

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

Accounts System Preferences

When a user installs Mac OS X on a computer, that user automatically becomes a member of 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. 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.

Keychain Access

Keychain Access is a utility that gives users access to Keychain Services (see “Keychain”). 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 “Certificates.”

The user can see and change passwords stored for various applications and can securely store other secrets such as 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.