Yasin Hasan Karanfil

Mac OS X and 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.

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 Performing
Privileged Operations With Authorization Services 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. 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 Performing Privileged Operations With Authorization Services and the BetterAuthorizationSample
sample code for more information on creating such a tool.
To learn how to use Authorization Services, start with Performing Privileged Operations With Authorization
Services 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/cd-
sa.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” (page 29)) 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.

Secure Communication

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” (page 32)). 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/CryptoToolk-
it/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” (page 29)). 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” (page 29).
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.

 

Source : Secure Coding Guide