Security overview 2

Contents
About Software Security 5
At a Glance 5
Threat Models Help You Identify Areas of Risk 6
Secure Coding Techniques and OS Security Features Help You Mitigate Those Risks 6
Tools Can Help You Catch Coding Errors 6
Prerequisites 7
Risk Assessment and Threat Modeling 8
Assessing Risk 8
Assume Your Software Will Be Attacked 8
Evaluate the Risk 9
Determining Potential Threats 10
Create a Threat Model 10
Consider Types of Threats 11
Mitigating Threats 12
Use Common Mitigation Techniques 12
Know the Trade-Offs 13
After You Finish 13
Common Criteria 14
To Learn More 14
Code Security 15
Code Hardening 15
Code Signing 16
Principle of Least Privilege 16
App Sandboxing 17
Privilege Separation 17
To Learn More 19
Authentication and Authorization 20
Authentication 20
Authorization 21
To Learn More 21
2012-12-13 | Copyright © 2012 Apple Inc. All Rights Reserved.
2

Cryptographic Services 23
Encryption and Decryption 23
Symmetric Encryption 24
Asymmetric Encryption 24
Steganography 25
Hashing 26
Signing and Verifying 27
Secure Storage 28
Keychains 28
FileVault 28
Data Protection 28
To Learn More 29
Security Server and Security Agent 30
Security Server 30
Security Agent 30
End-User Security Features 32
Security System Preferences 33
FileVault and Encrypted Volumes 33
Accounts System Preferences 34
Keychain Access 36
Mail 37
Other Security Resources 38
Other Apple Documentation 38
Third-Party Documentation 40
Standards and Protocol References 41
Document Revision History 42
3
Contents

Figures
End-User Security Features 32
Figure B-1 Security system preferences 33
Figure B-2 Accounts system preferences Security pane 35
Figure B-3 Accounts system preferences Limitations pane 36
4

In the cloud-enabled, highly networked world of modern computing, security is one of the most important
facets of proper software engineering.
The most important thing to understand about security is that it is not a bullet point item. You cannot bolt it
on at the end of the development process. You must consciously design security into your app or service from
the very beginning, and make it a conscious part of the entire process from design through implementation,
testing, and release.
Your app
At a Glance
At the application layer, security means being aware of how your code uses information and ensuring that it
does so safely and responsibly. For example, it is your responsibility to:
● Keep users’ personal data safe from prying eyes. Store the data in a secure way, and ensure that your
software collects only the information that it requires.
● Treat untrusted files and data with care. If your software accesses the Internet or reads files that might
have previously been sent to someone over the Internet, your software must properly validate the data.
If it does not, it might inadvertently provide a vector for attackers to access other personal data that may
be stored on the user’s computer or other mobile device.
● Protect data in transit. If your software transmits personal information over the Internet, you must do so
in a safe and secure fashion to prevent unauthorized access to or modification of the data while in transit.
5
About Software Security

● Verify the authenticity of data where possible. If your software provides access to or works with signed
data, it should verify those signatures to ensure that the data has not been tampered with.
Threat Models Help You Identify Areas of Risk
In the planning phase, you must determine the nature of the threats to your software and architect your code
in such a way that maximizes security. To do this, you should build up a threat model that shows ways in which
your software might be attacked.
Relevant Chapter: Risk Assessment and Threat Modeling (page 8)
Secure Coding Techniques and OS Security Features Help You Mitigate Those
Risks
At each phase of the development process, you must take steps to mitigate risks:
● Avoid exploitable coding flaws. During the implementation phase, you must avoid using insecure coding
techniques that can lead to arbitrary code injection, denial of service, or other incorrect behavior.
● Update your risk model continuously. Throughout the development process, you should continue to
perform regular risk assessments and update your threat model as the software evolves so that it accurately
reflects your risk.
● Don’t reinvent the wheel. When securing your software and its data, you should always take advantage
of built-in security features rather than writing your own if at all possible. In particular, you may need to
determine whether a user is legitimate or not, send messages to servers securely to protect the integrity
and secrecy of data in transit, or store data securely on local disks to protect data at rest.
Relevant Chapters: Code Security (page 15), Risk Assessment and Threat Modeling (page 8),
Authentication and Authorization (page 20), Cryptographic Services (page 23)
Tools Can Help You Catch Coding Errors
In the testing phase, you should take advantage of static analyzers and other tools designed to help you find
security vulnerabilities.
At a Glance
6

Relevant Chapters: Other Security Resources (page 38)
Prerequisites
This document assumes that you have already read Mac Technology Overview, iOS Technology Overview, or
both.
Prerequisites
7

Before you write a single line of code, take the time to design your software with security in mind. Doing this
correctly is genuinely hard; if your security analysis process seems easy, you’re probably missing something
fairly fundamental and losing most of the benefits of proper secure code design.
Risk assessment and threat modeling happens in three steps:
1. Assess risk. Determine how much you have to lose.
2. Determine potential threats. Figure out the various things your code does that could be attacked (including
things that frameworks and libraries do on your behalf).
3. Mitigate threats. Ensure that the parts of your code that could be attacked are well protected.
Assessing Risk
To assess the risk that your code would pose if compromised, you should first assume that your program will
be attacked.
Assume Your Software Will Be Attacked
The amount of time and effort that an attacker will spend attacking your program depends on several factors,
including:
● The value of the data your program handles. Does it store thousands of credit card numbers or a user’s
recipe collection?
● The trustworthiness and security of companies who provide services that your code depends on.
● The specific clients who purchased your program. Is your word processing app being used by Joe’s Auto
Repair or by Big Megacorp, Inc.?
● How widely your program will be distributed. Is it an app that is used by a single, small workgroup, or is
it built into an operating system that is about to be released worldwide?
8
Risk Assessment and Threat Modeling

Based on those same factors, you need to decide what level of risk is acceptable. A loss of data that will cost
your company $1000 to rectify doesn’t justify a $10,000 development effort to close all potential security bugs.
On the other hand, damage to your company’s reputation might be worth far more in the long run than it
would cost to design and develop secure code.
Evaluate the Risk
Here are some factors to consider when evaluating risk:
● What is the worst thing that can happen if your software is successfully attacked?
Will it allow theft of a user’s identity, allow an attacker to gain control of a user’s computer, or just enable
a hacker to get an unusually high score in pinball?
● How hard is it to mount a successful attack?
If exploiting a vulnerability would require installing a Trojan horse on the user’s computer that can take
advantage of a race condition that occurs only once in 50 times the program starts up, you might decide
the level of risk is acceptable. If the exploit can be put into a script and used by script kiddies (attackers
who run prewritten attack scripts) or be automated to spread by botnets (networks of compromised
computers), the level of risk is much higher.
● How big a target is it?
Did you sell a hundred copies of your app, or is it installed by default on hundreds of thousands of
computers?
Is it vulnerable by default, or only after a user chooses an unusual set of options?
● How many users would be affected?
An attack on an end user’s machine usually affects one or two people, but a denial of service attack on a
server might affect thousands of users if even one server is attacked. Similarly, a worm spread by a common
email program might infect thousands of computers.
● How accessible is the target?
Does running the program require local access, or does the program accept requests across a network?
Is authentication required in order to establish a connection, or can anyone send requests to the program?
Assessing Risk
9

Determining Potential Threats
A risk assessment gives you some indication of how likely you are to be attacked and how much damage an
attack could cause. The next step is to figure out how you might be attacked, including attacks on all of your
interests—not only attacks on your software but also on your servers, your company, and so on. To do this,
you create a threat model that describes places in which anything of value (information, money, and so on)
changes hands.
Create a Threat Model
The threat model for an app, daemon, or other software system should be a high-level data-flow model that
diagrams every spot in which information moves into or out of your code or between major parts of your code.
At a high level, it should include these pieces:
● The types of data your app will work with
● The situations in which your app must deal with untrusted data
● The types of data transport your app uses
● Ways that an attacker could exploit a piece of software that does what your app does
● Strategies for mitigating each of those types of exploits
For the purposes of this analysis, you should consider only theoretical categories of attack, not actual specific
attacks. For example, a word processor could be compromised if it mishandles a corrupted file in such a way
that allows an attacker to inject code. It is not important whether your specific code has specific bugs that
make this possible.
Some potential attack targets might include program input or output, stored data, and the program’s operating
environment.
● Program input. If an attacker can cause a buffer overflow, they might be able to run their own code or
otherwise compromise the user’s data or system.
● Program output (either to the user or to another software module). The attacker might be able to gain
access to private information stored on the system, or to read and modify the information being passed
between modules (a man-in-the-middle attack).
● Data stored on the system (either permanently, as in a database, or temporarily, as in a global variable).
This data could potentially be stolen and sent to an attacker, modified by an attacker, or otherwise
compromised.
● Program environment. A program’s execution environment includes its open file descriptors, environment
variables, Mach ports, preference files, and so on.
10

Consider Types of Threats
There are several types of threats to consider, including threats to data, service availability, and system integrity.
Threats to Data
An attacker can modify data. This includes:
● Data used internally by the program (such as interprocess messages)
● Data acted on by the program (such as numbers on which the program does a statistical analysis or an
audio track that the program filters)
● Data stored on disk to which the program gives access..
Similarly, an attacker can compromise data and obtain access to secrets.
An attacker can modify or compromise data directly by telling the program to modify or return data that it
shouldn’t have modified or returned. However, an attacker can also modify or compromise data indirectly by
using your program to take control of the computer.
Further, direct modifications often lead to further access that can allow additional indirect modifications. For
example, an attacker might modify internal program data directly, then use that modified data to inject arbitrary
code that adds a new admin user to the system’s password database.
Threats to Service Availability
An attack designed to reduce service availability is called a denial of service attack. These attacks can cause an
app or daemon to stop functioning, or make a server so busy that legitimate users can’t get access to it.
An attacker can perform a denial of service attack in many ways:
● Attacking bugs in the networking stack
● Open connections to the daemon, start sending a request, then continue sending it very, very slowly
● Convince thousands of people to voluntarily attack your server.
● Open millions of connections to the daemon from a botnet.
When a denial of service attack is carried out by a large number of machines, it is called a distributed denial of
service attack, or DDoS.
Attacks on System Integrity
Attacks on system integrity build upon other attacks to modify the system in such a way that it can no longer
be trusted. If an attacker can find a security flaw in your code, the attacker might be able to:
11

● Execute malicious code, especially with administrator or root access. The attacker might cause your
code to execute the attacker’s code by exploiting a buffer overflow or by code insertion in a URL command,
for example.
If your code is a daemon running with administrative privileges, the attacker’s code will be privileged as
well. Once an attacker has administrative control of a computer, any efforts to mitigate threats become
futile.
● Impersonate a user or server. The attacker might be able to guess or obtain a valid username and password
and therefore authenticate as an authorized user.
Similarly, a spoofed server might be able to convince a client app that it is a legitimate server, then get
the client to give it data or get the user to provide secrets, such as passwords.
Finally, a spoofed server might be able to convince a naïve user that the server is legitimate. For example,
a user might not examine the window containing a web page sufficiently to notice that the lock icon (or
other indicator of a secure site) is missing. Using such a malicious website to obtain user data is called
phishing.
● Repudiate an action. A malicious user might modify your software in such a way that allows him or her
to deny performing an operation (such as using a specific credit card number). There are a number of
techniques you can use to ensure nonrepudiation, such as code signature verification, data integrity checks,
and so on.
Mitigating Threats
After you have determined which parts of your software ecosystem (apps, servers, local daemons and agents,
and so on) might be attacked, you must take steps to mitigate those threats—that is, to make them less
damaging.
Use Common Mitigation Techniques
The means of mitigating threats in computer software are many and varied, but a few core techniques are
common:
● Take extra care when working with data from a potentially untrusted source. In particular, secure software
must always validate its inputs.
● Take advantage of sandboxing—setting developer-defined limits on what your app can do—to minimize
the damage that an app can cause if it gets compromised.
● Minimize the risk of information disclosure by compartmentalizing your apps and ensuring that each part
of an app can access only the information that it needs.
Mitigating Threats
12

● Perform fuzzing—sending bad data to your app or daemon to see if it breaks—and fix any bugs that you
find in the process.
● Take advantage of the security functionality built into the operating system instead of reinventing the
wheel.
Know the Trade-Offs
When deciding how to mitigate a threat, keep in mind that there are often tradeoffs between security and
convenience. Software security must strike a balance between security and usability. Consider two extreme
examples of software design:
● One program requires authentication using multiple authentication methods before performing any
operation, runs only long enough to perform that operation, does not share use of the CPU with any other
program, and then quits, requiring reauthorization for the next operation.
This mode of operation is very secure and might be appropriate for a program that launches nuclear
missiles, but few would want to use a word processor that acted like that.
● Another program always runs with root privileges and performs any operation you like without ever
requiring authorization.
Such a program is easy to use, and on a physically secure computer that is not connected to a network,
it might even be moderately safe. However, under most normal conditions, it would be a huge security
risk.
Clearly neither of these extremes strikes an optimal balance between security and user convenience. As a
developer, it is your responsibility to decide where your software should fit in this continuum based on the
damage that might occur if your program is compromised (the risk) and the types of attacks the software is
likely to face (the threat).
After You Finish
Even when you finish this assessment, your job is not done; you should repeat this assessment at regular
intervals along the way. In particular:
● Whenever you make any design decisions, consider how the design decisions change your threat models
and update your models accordingly.
● When you add new features or functionality, create threat models for those new components.
● As you code, be aware of the threat model and make sure your code follows its guidance.
After You Finish
13

In addition to avoiding bugs in the design, you must also take steps to ensure that your code is robust against
attacks on bugs in the implementation. You’ll learn more about how to do this in the next chapter.
Common Criteria
The governments of the United States, Canada, the United Kingdom, France, Germany, and the Netherlands
have worked together to develop a standardized process and set of standards that can be used to evaluate
the security of software products. This process and set of standards is called the Common Criteria.
As an attempt to systematize security evaluations, the Common Criteria can be helpful in suggesting a large
number of potential problems that you can look for. On the other hand, as with any standardization scheme,
the Common Criteria cannot anticipate vulnerabilities that haven’t been seen before. Therefore, the Common
Criteria standard is less flexible than one might wish.
Although opinions of security experts vary as to the value of a Common Criteria evaluation, some government
agencies cannot use software that hasn’t been through a full Common Criteria evaluation by an accredited
laboratory.
To Learn More
A number of third-party security books describe threat modeling in more detail. See Other Security
Resources (page 38) for a complete list.
Common Criteria
14

No software is perfect. Although many flaws are caused by design mistakes, some of the most devastating
flaws are caused by implementation mistakes. Design flaws and implementation flaws can compromise data
and can cause your software to misbehave. Attacks on implementation flaws can also sometimes cause your
software to execute arbitrary binary code provided by the attacker.
In preventing these attacks, threat models can only get you so far. They identify the parts of your infrastructure
that might reasonably be attacked, but they do not identify specific ways in which those pieces might be
attacked.
Therefore, when you implement your software, you must take steps to make it harder to compromise your
code. You must also minimize the potential for damage if an attacker does manage to compromise your code.
This chapter briefly summarizes how to write secure, robust code and describes operating system and compiler
features that make your job easier.
Code Hardening
Code hardening refers to fixing security holes in the code itself (as opposed to design mistakes). In essence,
code hardening is like repairing the bad mortar in a castle wall to prevent an attacker from breaching it, shoring
up the stern of a ship to repair a leak, or hiding a ruler’s secrets so that he or she cannot be blackmailed into
becoming a puppet ruler.
Here are some code-hardening techniques:
● Add code that validates inputs to prevent integer overflows.
● Replace any unsafe string function calls with calls that are buffer-size-aware to prevent buffer overflows.
● Avoid passing data to interpreters whenever possible. When the use of interpreters is unavoidable, pass
data to the interpreters in a safe fashion.
To prevent command injection attacks in SQL queries, use parameterized APIs (or manually quote the
strings if parameterized APIs are unavailable).
Avoid the POSIX system function.
● Set reasonable values for environment variables (PATH, USER, and so on) and do not make security decisions
based on their values.
● Fix bugs that cause race conditions; these can lead to incorrect behavior (or worse).
15
Code Security

At the end of this chapter, you’ll find a link to a document that describes these techniques in more detail, along
with other code-hardening techniques.
Code Signing
Code signing is a technology for ensuring the authenticity of executable code. By signing your code, the
operating system can verify that an app has not been modified by other software and can verify that updates
to that app were actually released by its author. Other technologies, such as the keychain and app sandboxing,
take advantage of this signature to better protect your users’ data.
To understand the details, however, you’ll have to learn a few more concepts. For this reason, code signing is
revisited in Cryptographic Services (page 23).
Principle of Least Privilege
The principle of least privilege states that a piece of code should, to the extent practical, run with exactly the
permissions it needs, and no more.
The closest analog in the physical world is designating certain areas for certain activities, and only allowing
people to enter those areas if they have a legitimate need to perform those activities. At a conference, for
example, the technical crew does not need access to the speaker support center, nor do the speakers (usually)
need access to the backstage areas.
In much the same way, your software should never take on or grant others any more permissions than are
necessary to do a particular job. For example, an app should not:
● Request elevated privileges unless absolutely necessary
● Relax permissions on portions of its app bundle
● Make unnecessary network connections
● Listen for connections on unnecessary network ports
● Listen for connections on public network interfaces inadvertently
● Read or write files in publicly writable folders unless directed to do so by the user
These are just a few examples. Because many of these activities are ancillary to your app’s main behavior, it is
critically important to regularly perform threat modeling as you add new code.
Code Security
Code Signing
16

App Sandboxing
To parents, a sandbox is a safe haven in which their children can play without needing to worry about them
getting hurt. It is a somewhat enclosed, safe environment, free from things that might injure them. And as
long as the children are inside the sandbox, they cannot (easily) be causing mischief outside the sandbox.
Similarly, in computing, the benefits of a sandbox are not limited to bad apps. Any app that contains security
holes can “go bad” if exploited properly, potentially causing the app to run arbitrary code. Thus, in computing,
sandboxes should be applied broadly—to all apps, ideally—ensuring that they cannot cause much harm if
they get compromised.
To achieve this goal, a sandbox limits an app’s capabilities to match its expected behavior (as defined by the
APIs that it uses and, in some cases, by a list of additional entitlements requested by the author of the app).
Thus, in computing, a sandbox more closely resembles the watchful eye of a Neighborhood Watch crime
prevention program. If someone appears who is acting suspicious, the neighbors can take action. In a similar
fashion, a sandboxed environment allows an app to do the things it normally would do. However, if it steps
out of line, the operation fails, and in some cases, the process is killed outright.
Privilege Separation
In an ideal world, writing software according to the principle of least privilege would be straightforward; the
user would grant each process just enough privilege required to do a job, and no more. However, this approach
can be challenging in practice, particularly when the nature of the job is poorly defined.
For a real-world example, a janitor needs to be able to take out the trash. A janitorial position does not typically
require a high security clearance. But suppose there is a trash can in a room filled with top-secret documents.
Because that trash can is ostensibly the janitor’s responsibility, the minimum privilege for the job is rather
broad—the janitor needs a high security clearance. A better solution is to move the trash can outside the door.
Alternatively, an employee who already has the necessary clearance could take the trash can out at the end
of the day.
In computers, the solution to this problem is privilege separation—breaking up a piece of software into multiple
pieces so that each piece individually requires fewer capabilities and so that those capabilities are protected
from inappropriate use by other parts of the app, tool, or daemon. This separation between pieces is called a
trust boundary.
For example, a word processor that accesses help files over a network might separate out the networking
portions into a separate help file downloader app. The main app should scrutinize the data sent back from this
helper, both to ensure that it was not tampered with during transit and to ensure that the helper, if compromised,
cannot easily attack the main app.
Code Security
App Sandboxing
17

Important: The distrust between the helpers and the main app must be mutual. The networking helper
in the previous example must carefully scrutinize the main app’s requests, ensuring that:
● All the requests go to the right server
● All the requests are for resources that the app is authorized to request
● HTTP redirects are followed only when appropriate
Without those checks, an attacker who compromised the main app could potentially use the networking
helper to forward a copy of the user’s data somewhere else.
Privilege separation is performed by writing a helper, daemon, or agent whose purpose is to do work on the
behalf of another piece of software. That helper, daemon, or agent may be sandboxed, unsandboxed, or
privileged.
● A sandboxed helper, daemon, or agent has fewer privileges than an ordinary app running as the user. It
may still have more permissions than the calling app, however, because the caller may be in an even
stricter sandbox.
● An unsandboxed helper, daemon, or agent has the same privileges as the user. However, because the
calling app may be running in a sandbox, this unsandboxed helper may have more privileges than the
caller.
● A privileged helper, daemon, or agent runs as another user who has broader permissions (often as the
root user, or superuser, which is essentially unlimited in terms of what operations it can perform).
Privileged helpers cannot be created within a sandboxed environment; however, they play a pivotal role
in making that environment more usable. For example, a privileged agent (privileged only because it is
running outside the sandbox) is used by the OS to provide a number of services to sandboxed apps, such
as the powerbox, which displays an “open file” dialog on behalf of the app and then temporarily adds the
chosen file to the app’s sandbox entitlements.
Because a differently privileged helper, daemon, or agent has the potential to allow its caller to significantly
violate established privilege boundaries, it must be written in such a way that limits what its caller can do. For
example, the powerbox allows an app to gain access to files outside the app’s container directory, but it does
so in a way that requires that the user take an explicit action to show consent.
OS X v10.7 introduced the XPC Services API for creating sandboxed helper apps that are specific to a single
app. These helper apps can have different privileges than the main app. OS X v10.8 and later also provides the
NSXPC API, which makes the process of privilege separation even more transparent by allowing the main app
to remotely call a specified set of methods on specific objects in the helper app and vice versa.
Code Security
18

To Learn More
For a more detailed conceptual overview of code hardening, read Secure Coding Guide.
To learn more about App Sandbox, read App Sandbox Design Guide.
For more information about XPC Services and NSXPC, read Daemons and Services Programming Guide.
You can also learn about other Apple and third-party security books in Other Security Resources (page 38).
Code Security
To Learn More
19

Code security protects the normal, day-to-day operations of an app, tool, or daemon. But what happens when
your code is under siege? It is often essential to know not only what the user is doing but also who the user
is and whether the user is allowed to do that. This is where authentication and authorization come into play.
Authentication
“If you know yourself but not your enemy, for every victory gained you will also suffer a defeat.”
—Sun Tzu, The Art of War
When securing software, the first thing you must do is find a way to distinguish friend from foe. This process
is called authentication.
In computer security, authentication verifies the identity of a user or service. Authentication usually serves one
of two purposes:
● As a precursor to authorization, identifying the requesting entity to determine whether that entity should
have permission to perform an operation
● For producing an audit trail by logging who performed an operation so that blame can be cast when
something breaks
Three types of authentication are most common:
● Local user authentication. Verifying a user’s identity is usually performed by the operating system as the
first step in authorization. If your code is running as a normal user, the operating system limits what your
code can do based on that user’s permissions. Your code can also ask the operating system for the identity
of the user for auditing purposes.
● Network host authentication. Verifying the authenticity of a remote server is often necessary—for example,
to determine whether it is safe to send credit card information to a specific website. (Digital certificates,
described in the next chapter, are a common way to achieve this.)
● Remote user authentication. Users are often authenticated by remote servers when performing certain
tasks. Authenticating a user remotely requires that your code send credentials in some form, such as a
password, a cookie, or a digital certificate.
20
Authentication and Authorization

Authorization
Authorization is the process by which an entity such as a user or a server gets permission to perform a restricted
operation. The term is also often used to refer to the right itself, as in “The soldier has authorization to enter
the command bunker.”
The difference between authentication and authorization is somewhat subtle. Often, the mere fact that a user
has an account means that the user is authorized to do something, in which case authentication and
authorization are the same thing. However, in more complex systems, the difference becomes more obvious.
Consider a computer with two users. Each user is known to the system. Therefore, both users can each log in
to the computer, and it authenticates them. However, neither user is authorized to modify the other’s files,
and as a result, neither user can do so.
The details of authorization depend on whether you are using iOS or OS X.
In iOS, the user can set a passcode (which by default is a four-digit personal identification number) to prevent
unauthorized use of the device. After entering this passcode, the user of the device is presumed to be authorized
to use the device. In addition, each app is digitally signed and can therefore be authenticated by the operating
system. Therefore, there are no user authentication or authorization APIs in iOS.
In OS X, there are several layers of authorization:
● If FileVault 2 (full-disk encryption) is enabled, the computer requires a password to decrypt the boot
volume.
● If automatic login is disabled, OS X displays a login screen after booting.
● OS X also displays a login screen when the user logs out.
● If the appropriate checkbox in the Security system preferences pane is checked, OS X displays a login
screen when waking from sleep or when leaving a screen saver.
● When an app or tool requests access to a locked keychain, a password is required.
● If an app or tool needs elevated privileges, an administrator password is required.
● Some apps may restrict access to parts of their functionality through the Authorization Services API.
In addition, on both OS X and iOS, some apps may require you to log in to a remote server, which in turn
performs authentication and authorization.
To Learn More
For a more detailed conceptual overview of authentication and authorization in OS X, read Authentication,
Authorization, and Permissions Guide.
Authorization
21

To Learn More
22

Cryptographic services form the foundation of securing data in transit (secure communications) and data at
rest (secure storage). Using sophisticated mathematics, they allow you to:
● Encrypt and decrypt data so that it cannot be understood by an outside observer
● Verify that data has not been modified since it was originally sent by hashing, signing, and verifying
This chapter describes these cryptographic techniques and briefly summarizes the technologies that OS X and
iOS provide to help you use cryptography in your own application.
Encryption and Decryption
Encryption is a means of protecting data from interception by transforming it into a form that is not readable
except by someone who knows how to transform it back.
Encryption is commonly used to protect data in transit and data at rest. When information must be sent across
an untrusted communication channel, it is the responsibility of the two endpoints to use encryption to secure
the communication. Similarly, when storing information on a local disk, an app may use encryption to ensure
that the information is not readable by third parties even if the computer is stolen.
There are many different encryption techniques, called ciphers, that work in different ways and can serve
different purposes. Ciphers generally work by combining the original information (the cleartext, or plaintext)
with a second piece of information (a key) in some fashion to produce an encrypted form, called the ciphertext.
Modern encryption techniques can be grouped into three broad categories: symmetric encryption, asymmetric
encryption, and steganography.
23
Cryptographic Services

Symmetric Encryption
In symmetric encryption, a single key (usually a long string of random bytes) is used to mathematically transform
a piece of information and is later used in reverse to retrieve the original information.
Shared secret key Shared secret key
Sender
Symmetric
Receiver
Symmetric encryption is often used for secure communication. However, because both endpoints must know
the same secret key, symmetric encryption is not sufficient by itself.
Asymmetric Encryption
In asymmetric encryption, two mathematically related keys are used to transform a piece of information.
Information encrypted with one key can be decrypted only with the other key and vice versa. Generally speaking,
one of these keys (the private key) is kept secret, and the other key (the public key) is made broadly available.
For this reason, asymmetric encryption is also called public key cryptography.
24

Note: Although the two keys are mathematically related, it is considered computationally infeasible
to derive one key from the other. The security of public key cryptography depends on this being the
case.
Asymmetric Encryption
Public key
Ciphertext
Ciphertext
Plaintext
Plaintext
Plaintext
Plaintext
Private key
Private key
or
Public key
10011
010111
11010
100010
ABCDE
FGHIJK
LMNOP
QRSTUV
ABCDE
FGHIJK
LMNOP
QRSTUV
Cipher Cipher
10011
010111
11010
100010
Cipher Cipher
Asymmetric encryption is often used for establishing a shared communication channel. Because asymmetric
encryption is computationally expensive, the two endpoints often use asymmetric encryption to exchange a
symmetric key, and then use a much faster symmetric encryption algorithm for encrypting and decrypting the
actual data.
Asymmetric encryption can also be used to establish trust. By encrypting information with your private key,
someone else can read that information with your public key and be certain that it was encrypted by you.
Steganography
Steganography means hiding information in less important bits of another piece of information.
Sender Receiver
Unencrypted Message
Steganography
to be or
not to
be that
is the
question
to be or
not to
be that
is the
question
Unencrypted MessageEncrypted Message
stovqtbexcor
rtbnotlktows
qybefgthatpf
waismthevs
ewquestionla
Encryption
Algorithm
Decryption
Algorithm
25

Steganography is commonly used for storing copyright information into photographs in such a way that is
largely indistinguishable from noise unless you know how to look for it.
Steganography can also be used for storing encrypted volumes underneath other encrypted or unencrypted
volumes (either by using the unused blocks or by taking advantage of error correction in subtle ways).
Hashing
A hash value, or hash, is a small piece of data derived from a larger piece of data that can serve as a proxy for
that larger piece of data. In cryptography, hashes are used when verifying the authenticity of a piece of data.
Cryptographic hashing algorithms are essentially a form of (extremely) lossy data compression, but they are
specifically designed so that two similar pieces of data are unlikely to hash to the same value.
For example, two schoolchildren frequently passed notes back and forth while deciding when to walk home
together. One day, a bully intercepted the note and arranged for Bob to arrive ten minutes early so that he
could steal Bob’s lunch money. To ensure that their messages were not modified in the future, they devised
a scheme in which they computed the remainder after dividing the number of letters in the message by the
sum of their ages, then wrote that many dots in the corner of the message. By counting the number of letters,
they could (crudely) detect certain modifications to each other’s messages.
This is, of course, a contrived example. A simple remainder is a very weak hashing algorithm. With good hashing
algorithms, collisions are unlikely if you make small changes to a piece of data. This tamper-resistant nature
of good hashes makes them a key component in code signing, message signing, and various other tamper
detection schemes.
At a high level, hashing is also similar to checksumming (a technique for detecting and correcting errors in
transmitted data). However, the goals of these techniques are very different, so the algorithms used are also
very different. Checksums are usually designed to allow detection and repair of a single change or a small
number of changes. By contrast, cryptographic hashes must reliably detect a large number of changes to a
single piece of data but need not tell you how the data changed.
For example, the following command in the shell demonstrates a common hashing algorithm:
$ echo "This is a test. This is only a test." | sha1sum
7679a5fb1320e69f4550c84560fc6ef10ace4550 -
OS X provides a number of C language APIs for performing hashing. These are described further in the documents
cited at the end of this chapter.
Hashing
26

Signing and Verifying
A signature is a way to prove the authenticity of a message, or to verify the identity of a server, user, or other
entity.
In olden days, people sometimes stamped envelopes with a wax seal. This seal not only proved who sent the
message but also proved that no one had opened the message and potentially modified it while in transit.
Modern signing achieves many of the same benefits through mathematics. In addition to the data itself, signing
and verifying require two pieces of information: the appropriate half of a public-private key pair and a digital
certificate.
The sender computes a hash of the message and encrypts it with the private key. The recipient also computes
a hash and then uses the corresponding public key to decrypt the sender’s hash and compares the hashes. If
they are the same, the data was not modified in transit, and you can safely trust that the data was sent by the
owner of that key.
The sender’s digital certificate is a collection of data that contains a public key and other identifying information,
at the sender’s discretion, such as a person’s name, a company name, a domain name, and a postal address.
The purpose of the certificate is to tie a public key to a particular person. If you trust the certificate, you also
trust that messages signed by the sender’s private key were sent by that person.
To provide a means of determining the legitimacy of a certificate, the sender’s certificate is signed by someone
else, whose certificate is in turn signed by someone else, and so on, forming a chain of trust to a certificate
that the recipient inherently trusts, called an anchor certificate. This certificate may be a root certificate—a
self-signed certificate that represents a known certificate authority and thus the root of the tree of certificates
originating from that authority—or it may be any arbitrary certificate that the user or application developer
has explicitly designated as a trusted anchor.
Because the recipient trusts the anchor certificate, the recipient knows that the certificate is valid and, thus,
that the sender is who he or she claims to be. The degree to which the recipient trusts a certificate is defined
by two factors:
● Each certificate can contain one or more certificate extensions that describe how the certificate can be
used. For example, a certificate that is trusted for signing email messages might not be trusted for signing
executable code.
● The trust policy allows you to trust certificates that would otherwise be untrusted and vice versa.
A certificate can also be used for authentication. By signing a nonce (a randomly generated challenge string
created specifically for this purpose), a user or server can prove that he, she, or it is in possession of the private
key associated with that certificate. If that certificate is considered trusted (by evaluating its chain of trust),
then the certificate and signed nonce prove that the user or server must be who he, she, or it claims to be.
Signing and Verifying
27

Secure Storage
OS X and iOS provide a number of technologies for secure storage. Of these, the three most commonly used
technologies are keychains, FileVault, and data protection.
Keychains
In concept, a keychain is similar to a physical key ring in that it is a place where keys and other similarly small
pieces of data can be stored for later use in performing cryptographic tasks, but the similarity ends there. With
a physical key ring, the owner can take the key and use it to unlock something. With a keychain, apps usually
do not access the actual key data itself, so they do not risk exposing the keys even if compromised. Instead,
they use a unique identifier to identify those keys, and the actual encryption is performed in a separate process
called the Security Server (described later in this document).
Thus, a keychain is in some ways more like a heavily armed security guard in full body armor who carries a key
ring. You can ask that guard to unlock a door for you if you are authorized to enter, but you usually can’t unlock
the door yourself.
OS X also includes a utility that allows users to store and read the data in the keychain, called Keychain Access.
This utility is described in more detail later, in Keychain Access.
FileVault
In OS X, FileVault uses encryption to provide encrypted storage for the user’s files. When FileVault is enabled,
the disk is decrypted only after an authorized user logs in. (Note that prior to OS X v10.7, FileVault protected
only a user’s home directory.)
FileVault and its configuration UI are described in more detail later, in End-User Security Features.
Data Protection
iOS provides APIs that allow an app to make files accessible only while the device is unlocked to protect their
contents from prying eyes. With data protection, files are stored in encrypted form and are decrypted only
after the user enters his or her passcode.
For apps that run in the background, there are also settings that allow the file to remain available until the
user shuts down the device.
Secure Storage
28

To Learn More
For a more detailed conceptual overview of authentication and authorization in OS X, read Cryptographic
Services Guide.
To learn more about creating signing certificates, read Creating Your Signing Certificates in App Distribution
Guide.
To Learn More
29

The OS X and iOS 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. OS X also
includes a separate per-user agent, called the Security Agent, that is used by the Security Server to display a
user interface.
This appendix briefly describes their roles.
Security Server
The SecurityServer (securityd) is a daemon running in OS X and iOS that implements several security protocols,
such as encryption, decryption, and (in OS X) authorization computation.
In OS X and iOS, the Security Server listens for messages from various security APIs and performs cryptographic
services on their behalf. Because developers generally use references to keys rather than using the keys
themselves, the Security Server can keep those keys in a separate address space from the client process, thus
reducing the risk of accidental disclosure.
As an added advantage, whenever Apple introduces new authentication or encryption technology, existing
software that uses the OS X security APIs can transparently support it without code changes, provided that
the software does not need to import or export keys directly.
The Security Server has no public API. Instead, your code calls APIs such as Keychain Services; Certificate, Key,
and Trust Services; and Authorization Services (only on OS X), which in turn communicate with the Security
Server.
Security Agent
The Security Agent is a separate process that provides the user interface for the Security Server in OS X (not
iOS). Its primary purpose is to request authentication whenever an app requests additional privileges.
30
Security Server and Security Agent

When the Security Server requires the user to authenticate, the Security Agent displays a dialog requesting a
user name and password. The advantages of performing this action in a separate process are twofold. First, an
application can obtain authorization without ever having access to the user’s credentials (username and
password, for example). Second, it enables Apple to add new forms of authentication without requiring every
application to understand them.
The Security Agent requires that the user be physically present in order to be authenticated. Because the
graphical user interface elements can’t be used through a command-line interface such as the Terminal app
or a secure shell (ssh) remote session, this restriction makes it much more difficult for a malicious user to
breach an app’s security.
Note: iOS security services do not provide an authentication interface. Thus, there is no need for
the Security Server to have a user interface, and as a result, iOS does not provide a Security Agent.
Security Server and Security Agent
Security Agent
31

OS X and iOS have many built-in security features, including industry-standard digital signatures and encryption
for Apple’s Mail app, and authentication for the Safari web browser.
In iOS, these features are largely invisible to the user, because security is handled by the system without the
user’s intervention.
In OS X, the following four features are most visible to users:
● The Security system preferences pane
● FileVault, which users can configure through the Security system preferences pane
● The Accounts system preferences pane
● The Keychain Access app
These features are described in this appendix.
32
End-User Security Features

Security System Preferences
Security system preferences in OS X let the user configure FileVault and control some aspects of authorization
on the computer (Figure B-1).
Figure B-1 Security system preferences
The Security system preferences dialog lets the user specify whether authorization should be required:
● When the computer first boots (automatic login)
● To wake the computer from sleep or a screen saver
● To unlock each lockable system preference
At the bottom of the dialog is the lock icon provided by the authorization view (see Designing Secure User
Interfaces in Secure Coding Guide). When this icon shows a closed lock, authorization is required before the
user can change the settings in this system preferences pane.
FileVault and Encrypted Volumes
When the user turns on FileVault (see Figure B-1), OS X uses 128-bit AES encryption to encrypt everything on
the root volume (or everything in the user’s home folder prior to OS X v10.7).
Security System Preferences
33

The system automatically decrypts files upon access if an authorized user is logged in, but the files remain
encrypted on disk. This provides maximum security for a user’s files if all of the following are true:
● All sensitive data is stored on an encrypted volume (or in the user’s home directory prior to OS X v10.7).
● Permissions are set appropriately to protect the data from other users on the system.
● Automatic login is disabled.
● A password is required to wake from sleep or to wake from the screen saver.
A user can also create new external volumes with FileVault encryption using Disk Utility. Alternatively, if a user
wants to securely store files somewhere other than a FileVault-protected volume (such as on an external hard
disk or removable media), the user can create an encrypted disk image.
For more information about FileVault, see Apple Knowledge Base Article HT4790.
Accounts System Preferences
When a user installs OS X on a computer, that user automatically becomes a member of the admin group
(described in The Admin Group). Subsequently, the user or any other member of the admin group can use the
Accounts system preferences panes to add new users to the system.
34

For each new user, the administrator can specify whether that user should be a member of the admin group
(Figure B-2).
Figure B-2 Accounts system preferences Security pane
35

If the new user is not a member of the admin group, the administrator can limit the system features and apps
to which that user has access (Figure B-3).
Figure B-3 Accounts system preferences Limitations pane
Users in the admin group can turn on FileVault encryption.
Keychain Access
Keychain Access is an OS X utility that lets users see and modify the passwords, certificates, and other data that
are stored in their keychains.
With Keychain Access, users can:
● Create new keychains
● Add and delete keychain items
● Lock and unlock keychains
● Choose one keychain to be the default
Keychain Access
36

● See which certificates are available for use by email and web apps, who owns each certificate, and who
issued each certificate
● See and change passwords stored for various apps, tools, and websites
● Securely store other secrets, such as passwords, credit card numbers, and notes
When a keychain is locked and an app or other tool 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, or change a ticket’s
password. Kerberos is described in more detail in Authentication, Authorization, and Permissions Guide.
Mail
Apple’s Mail app and other email apps can extract a public key from the signing certificate of any signed email
and use it to encrypt messages sent to the owner of that key. See Digital Signatures in Cryptographic Services
Guide for more information about digital signatures, and see Help in the Mail app for details on sending
encrypted email.
Mail
37

Now that you’ve read about the basics, there are a few more things you should learn. First, read these two
documents:
● App Sandbox Design Guide tells you the things you need to know about designing code to run in a
sandboxed environment before you write the first line of code.
● Secure Coding Guide describes in more detail how to design code in ways that maximize security, and also
describes what you should do while actually writing the code to avoid security holes.
When you’re ready to test your code, read Debug and Tune Your App in Xcode Overview. This document
explains how to use the static analyzer in Xcode, which is a great way to find a lot of common security bugs.
After reading those documents, consider reading some of the documents listed in the rest of this appendix.
Other Apple Documentation
Here are a few other Apple documents you might be interested in, depending on what technologies you want
to learn more about.
● Authentication,Authorization,andPermissionsGuide providesadditionalinformationaboutauthentication
and authorization at a conceptual level. (OS X only)
● Authorization Services Programming Guide and Authorization Services C Reference explain how to perform
certain authorization-related tasks. (OS X only; note that many of these tasks, such as elevating privilege,
are not allowed in a sandboxed environment)
● Open Directory Programming Guide explains how to use Open Directory APIs to authenticate a user or
obtain information about a user. (OS X only)
● Security Interface Framework Reference describes the Objective-C interface to Authorization Services. This
interface also provides a variety of security-related user interface elements. (OS X only)
● Technical Note TN2095, Authorization for Everyone, also discusses the use of Authorization Services. (OS
X only)
Cryptography
38
Other Security Resources

● Cryptographic Services Guide describes encryption, decryption, signing, verifying, digital certificates, and
other related concepts in more detail at a conceptual level.
● Security Transforms Programming Guide and Security Transforms Reference describe the preferred OS X
API for most cryptographic tasks. (OS X only)
● Certificate, Key, and Trust Services Programming Guide and Certificate, Key, and Trust Services Reference
explain how to work with certificates, keys, and other related technologies in more detail.
Code And Application Signing
● CryptographyConceptsInDepthinCryptographicServicesGuide explainscodesigningconceptsingreater
depth.
● Creating Your Team’s Signing Certificates in Developing for the App Store shows you how to set up code
signing in Xcode.
● Code Signing Guide tells you how to perform code signing on the command line and other unusual
signing-related tasks.
Secure Storage
● KeychainServicesProgrammingGuide andKeychainServicesReference explainhowtousetheOSXkeychain
in your code.
● Advanced App Tricks in iOS App Programming Guide explains how to use the iOS data protection feature
in your app. (iOS only)
Secure Networking
● CFNetwork Programming Guide and URL Session Programming Guide explain how to make secure network
connections using high-level APIs.
● Secure Transport Reference tells how to make secure network connections at the socket layer. (OS X only)
● Designing Secure Helpers and Daemons in Secure Coding Guide provides guidance on how to securely
perform privilege separation.
● Daemons and Services Programming Guide describes XPC services, which is the preferred way of launching
and communicating with helper apps in a sandboxed environment. (OS X only)
Miscellaneous
Other Apple Documentation
39

● Apple's Open Source website provides Apple’s open source security code. You can examine it to see which
security protocols and algorithms are supported by Apple’s OS X and iOS security implementation and to
find additional documentation.
● The Security topic areas in the OS X Developer Library and the iOS Developer Library contain a number
of security-specific release notes.
Third-Party Documentation
There are a number of excellent books on computer security that you should consider reading. Here are just
a few of them, grouped into subject areas.
Cocoa Security
● Lee, Graham J. Professional Cocoa Application Security, Wrox Professional Guides, 2010.
Threat Modeling
● Howard, Michael, and David LeBlanc. Writing Secure Code (second edition), Microsoft Press, 2003.
● Anderson, Ross. Security Engineering: A Guide to Building Dependable Distributed Systems, 2d ed.
John Wiley & Sons, 2001.
Fuzz Testing
● Sutton, Michael, Adam Greene, and Pedram Amini. Fuzzing: Brute Force Vulnerability Discovery,
Pearson Education, 2007.
Cryptography
● Schneier, Bruce. Applied Cryptography. 2d ed. John Wiley & Sons. 1996.
● Brands, Stefan. Rethinking PKI and Digital Certificates: Building in Privacy. The MIT Press. 2000.
Secure Networking
● Gray, John Shapley. Interprocess Communications in UNIX. 2d ed. Prentice Hall Professional. 1997.
● Stevens, W. Richard. UNIX Network Programming: Interprocess Communications. Vol. 2, 2d ed.
Prentice Hall Professional. 1998.
● Stevens, W. Richard, Bill Fenner, and Andres M. Rudoff. UNIX Network Programming: The Sockets
Networking API. Vol. 1. 3d ed. Addison Wesley Professional. 2004.
General
● Garfinkel, Simson, Gene Spafford, and Alan Schwartz. Practical Unix & Internet Security. 3d ed.
O’Reilly. 2003.
● Viega, John, and Gary McGraw. Building Secure Software. Addison-Wesley Professional. 2002.
Third-Party Documentation
40

● McKusick, Marshall Kirk, Keith Bostic, Michael Karels, and John Quarterman. The Design and
Implementation of the 4.4 BSD Operating System. Addison-Wesley. 1996.
Standards and Protocol References
The following pages describe some of the standards, protocols, and algorithms used by Apple. Although many
of these pages are fairly old, the standards have not changed enough to invalidate their usefulness.
Common Criteria
● For more information about the Common Criteria, including links to download the complete official criteria,
see the Common Criteria portal at http://www.commoncriteriaportal.org/ and the website of the Common
Criteria Evaluation and Validation Scheme (CCEVS) (http://www.niap-ccevs.org/cc-scheme/).
Kerberos
● For information on Kerberos authentication, see the MIT Kerberos website.
● See OS X Server Open Directory Administration available at http://www.apple.com/server/documentation/
for details on the services that support Kerberos and on how to implement a Kerberos KDC on your OS X
server.
Other Secure Networking Protocols
● The authentication model for HTTP is described in RFC 2617, HTTP Authentication: Basic and Digest Access
Authentication.
● For information on the SSL protocol for secure networking, see the IETF SSL Version 3.0 Draft Specification.
For the TLS protocol, see the TLS Working Group website and RFC 5246.
● Documentation of the AES encryption algorithm used for FileVault is available on the National Institute
of Standards and Technology (NIST) website.
Standards and Protocol References
41

This table describes the changes to Security Overview.
NotesDate
Made additional editorial changes throughout.2012-12-13
Made minor editorial fixes.2012-09-19
Made minor typographical fixes.2012-06-11
Corrected minor errors in the bibliography.2012-03-06
Introduces computer security concepts.2012-01-09
Added information about sandboxing.2011-07-06
Reorganized file system permissions into a single section and enhanced
the content.
2010-07-13
Added a link to the iOS Technology Overview.2008-10-15
Added information about security in iOS.2008-06-26
Added descriptions of new features for OS X v10.5.2008-02-08
Updated for OS X v10.4. Added information about file-system access
control lists (ACLs). Changed "Rendezvous" to "Bonjour."
2005-04-29
42
Document Revision History

NotesDate
New document that introduces computer security concepts and describes
the security features and APIs in OS X.
2004-02-23
Document Revision History
43

Apple Inc.
Copyright © 2012 Apple Inc.
All rights reserved.
No part of this publication may be reproduced,
stored in a retrieval system, or transmitted, in any
form or by any means, mechanical, electronic,
photocopying, recording, or otherwise, without
prior written permission of Apple Inc., with the
following exceptions: Any person is hereby
authorized to store documentation on a single
computer or device for personal use only and to
print copies of documentation for personal use
provided that the documentation contains
Apple’s copyright notice.
No licenses, express or implied, are granted with
respect to any of the technology described in this
document. Apple retains all intellectual property
rights associated with the technology described
in this document. This document is intended to
assist application developers to develop
applications only for Apple-branded products.
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
408-996-1010
Apple, the Apple logo, Bonjour, Cocoa, FileVault,
Keychain, Mac, Objective-C, OS X, Safari, Sand,
and Xcode are trademarks of Apple Inc.,
registered in the U.S. and other countries.
App Store is a service mark of Apple Inc.
IOS is a trademark or registered trademark of
Cisco in the U.S. and other countries and is used
under license.
UNIX is a registered trademark of The Open
Group.
APPLE MAKES NO WARRANTY OR REPRESENTATION,
EITHER EXPRESS OR IMPLIED, WITH RESPECT TO THIS
DOCUMENT, ITS QUALITY, ACCURACY,
MERCHANTABILITY, OR FITNESS FOR A PARTICULAR
PURPOSE. AS A RESULT, THIS DOCUMENT IS PROVIDED
“AS IS,” AND YOU, THE READER, ARE ASSUMING THE
ENTIRE RISK AS TO ITS QUALITY AND ACCURACY.
IN NO EVENT WILL APPLE BE LIABLE FOR DIRECT,
INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
DAMAGES RESULTING FROM ANY DEFECT, ERROR OR
INACCURACY IN THIS DOCUMENT, even if advised of
the possibility of such damages.
Some jurisdictions do not allow the exclusion of
implied warranties or liability, so the above exclusion
may not apply to you.

Security overview 2

More Related Content

What's hot

Viewers also liked

Similar to Security overview 2

More from CMR WORLD TECH

Recently uploaded

Security overview 2