security overview 2

Security Overview

Contents

About Software Security 5At a Glance 5

Threat Models Help You Identify Areas of Risk 6Secure Coding Techniques and OS Security Features Help You Mitigate Those Risks 6Tools Can Help You Catch Coding Errors 6

Prerequisites 7

Risk Assessment and Threat Modeling 8Assessing Risk 8

Assume Your Software Will Be Attacked 8Evaluate the Risk 9

Determining Potential Threats 10Create a Threat Model 10Consider Types of Threats 11

Mitigating Threats 12Use Common Mitigation Techniques 12Know the Trade-Offs 13

After You Finish 13Common Criteria 14To Learn More 14

Code Security 15Code Hardening 15Code Signing 16Principle of Least Privilege 16App Sandboxing 17Privilege Separation 17To Learn More 19

Authentication and Authorization 20Authentication 20Authorization 21To Learn More 21

2012-12-13 | Copyright © 2012 Apple Inc. All Rights Reserved.

2

Cryptographic Services 23Encryption and Decryption 23

Symmetric Encryption 24Asymmetric Encryption 24Steganography 25

Hashing 26Signing and Verifying 27Secure Storage 28

Keychains 28FileVault 28Data Protection 28

To Learn More 29

Security Server and Security Agent 30Security Server 30Security Agent 30

End-User Security Features 32Security System Preferences 33FileVault and Encrypted Volumes 33Accounts System Preferences 34Keychain Access 36Mail 37

Other Security Resources 38Other Apple Documentation 38Third-Party Documentation 40Standards and Protocol References 41

Document Revision History 42


3

Contents

Figures

End-User Security Features 32Figure B-1 Security system preferences 33Figure B-2 Accounts system preferences Security pane 35Figure 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 importantfacets of proper software engineering.

The most important thing to understand about security is that it is not a bullet point item. You cannot bolt iton at the end of the development process. You must consciously design security into your app or service fromthe very beginning, and make it a conscious part of the entire process from design through implementation,testing, and release.

Your app

At a GlanceAt the application layer, security means being aware of how your code uses information and ensuring that itdoes 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 yoursoftware collects only the information that it requires.

● Treat untrusted files and data with care. If your software accesses the Internet or reads files that mighthave 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 maybe 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 soin 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 signeddata, it should verify those signatures to ensure that the data has not been tampered with.

Threat Models Help You Identify Areas of RiskIn the planning phase, you must determine the nature of the threats to your software and architect your codein such a way that maximizes security. To do this, you should build up a threat model that shows ways in whichyour software might be attacked.

Relevant Chapter: Risk Assessment and Threat Modeling (page 8)

Secure Coding Techniques and OS Security Features Help You Mitigate ThoseRisksAt 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 codingtechniques 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 toperform regular risk assessments and update your threat model as the software evolves so that it accuratelyreflects your risk.

● Don’t reinvent the wheel. When securing your software and its data, you should always take advantageof built-in security features rather than writing your own if at all possible. In particular, you may need todetermine whether a user is legitimate or not, send messages to servers securely to protect the integrityand 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 ErrorsIn the testing phase, you should take advantage of static analyzers and other tools designed to help you findsecurity vulnerabilities.

About Software SecurityAt a Glance


6

Relevant Chapters: Other Security Resources (page 38)

PrerequisitesThis document assumes that you have already read Mac Technology Overview , iOS Technology Overview , orboth.

About Software SecurityPrerequisites


7

Before you write a single line of code, take the time to design your software with security in mind. Doing thiscorrectly is genuinely hard; if your security analysis process seems easy, you’re probably missing somethingfairly 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 (includingthings 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 RiskTo assess the risk that your code would pose if compromised, you should first assume that your program willbe attacked.

Assume Your Software Will Be AttackedThe 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’srecipe 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 AutoRepair 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 isit 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 costyour 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 itwould cost to design and develop secure code.

Evaluate the RiskHere 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 enablea 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 takeadvantage of a race condition that occurs only once in 50 times the program starts up, you might decidethe level of risk is acceptable. If the exploit can be put into a script and used by script kiddies (attackerswho run prewritten attack scripts) or be automated to spread by botnets (networks of compromisedcomputers), 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 ofcomputers?

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 aserver might affect thousands of users if even one server is attacked. Similarly, a worm spread by a commonemail 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?

Risk Assessment and Threat ModelingAssessing Risk


9

Determining Potential ThreatsA risk assessment gives you some indication of how likely you are to be attacked and how much damage anattack could cause. The next step is to figure out how you might be attacked, including attacks on all of yourinterests—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 ModelThe threat model for an app, daemon, or other software system should be a high-level data-flow model thatdiagrams 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 specificattacks. For example, a word processor could be compromised if it mishandles a corrupted file in such a waythat allows an attacker to inject code. It is not important whether your specific code has specific bugs thatmake this possible.

Some potential attack targets might include program input or output, stored data, and the program’s operatingenvironment.

● Program input. If an attacker can cause a buffer overflow, they might be able to run their own code orotherwise compromise the user’s data or system.

● Program output (either to the user or to another software module). The attacker might be able to gainaccess to private information stored on the system, or to read and modify the information being passedbetween 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 otherwisecompromised.

● Program environment. A program’s execution environment includes its open file descriptors, environmentvariables, Mach ports, preference files, and so on.

Risk Assessment and Threat ModelingDetermining Potential Threats


10

Consider Types of ThreatsThere are several types of threats to consider, including threats to data, service availability, and system integrity.

Threats to DataAn 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 anaudio 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 itshouldn’t have modified or returned. However, an attacker can also modify or compromise data indirectly byusing your program to take control of the computer.

Further, direct modifications often lead to further access that can allow additional indirect modifications. Forexample, an attacker might modify internal program data directly, then use that modified data to inject arbitrarycode that adds a new admin user to the system’s password database.

Threats to Service AvailabilityAn attack designed to reduce service availability is called a denial of service attack . These attacks can cause anapp 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 ofservice attack , or DDoS .

Attacks on System IntegrityAttacks on system integrity build upon other attacks to modify the system in such a way that it can no longerbe trusted. If an attacker can find a security flaw in your code, the attacker might be able to:

Risk Assessment and Threat ModelingDetermining Potential Threats


11

● Execute malicious code, especially with administrator or root access. The attacker might cause yourcode 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 aswell. Once an attacker has administrative control of a computer, any efforts to mitigate threats becomefutile.

● Impersonate a user or server. The attacker might be able to guess or obtain a valid username and passwordand 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 getthe 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 (orother indicator of a secure site) is missing. Using such a malicious website to obtain user data is calledphishing .

● Repudiate an action. A malicious user might modify your software in such a way that allows him or herto deny performing an operation (such as using a specific credit card number). There are a number oftechniques you can use to ensure nonrepudiation, such as code signature verification, data integrity checks,and so on.

Mitigating ThreatsAfter 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 lessdamaging.

Use Common Mitigation TechniquesThe means of mitigating threats in computer software are many and varied, but a few core techniques arecommon:

● Take extra care when working with data from a potentially untrusted source. In particular, secure softwaremust always validate its inputs.

● Take advantage of sandboxing—setting developer-defined limits on what your app can do—to minimizethe damage that an app can cause if it gets compromised.

● Minimize the risk of information disclosure by compartmentalizing your apps and ensuring that each partof an app can access only the information that it needs.

Risk Assessment and Threat ModelingMitigating Threats


12

● Perform fuzzing—sending bad data to your app or daemon to see if it breaks—and fix any bugs that youfind in the process.

● Take advantage of the security functionality built into the operating system instead of reinventing thewheel.

Know the Trade-OffsWhen deciding how to mitigate a threat, keep in mind that there are often tradeoffs between security andconvenience. Software security must strike a balance between security and usability. Consider two extremeexamples of software design:

● One program requires authentication using multiple authentication methods before performing anyoperation, runs only long enough to perform that operation, does not share use of the CPU with any otherprogram, 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 nuclearmissiles, 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 everrequiring 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 securityrisk.

Clearly neither of these extremes strikes an optimal balance between security and user convenience. As adeveloper, it is your responsibility to decide where your software should fit in this continuum based on thedamage that might occur if your program is compromised (the risk) and the types of attacks the software islikely to face (the threat).

After You FinishEven when you finish this assessment, your job is not done; you should repeat this assessment at regularintervals along the way. In particular:

● Whenever you make any design decisions, consider how the design decisions change your threat modelsand 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.

Risk Assessment and Threat ModelingAfter You Finish


13

In addition to avoiding bugs in the design, you must also take steps to ensure that your code is robust againstattacks on bugs in the implementation. You’ll learn more about how to do this in the next chapter.

Common CriteriaThe governments of the United States, Canada, the United Kingdom, France, Germany, and the Netherlandshave worked together to develop a standardized process and set of standards that can be used to evaluatethe 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 largenumber 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 CommonCriteria standard is less flexible than one might wish.

Although opinions of security experts vary as to the value of a Common Criteria evaluation, some governmentagencies cannot use software that hasn’t been through a full Common Criteria evaluation by an accreditedlaboratory.

To Learn MoreA number of third-party security books describe threat modeling in more detail. See Other SecurityResources (page 38) for a complete list.

Risk Assessment and Threat ModelingCommon Criteria


14

No software is perfect. Although many flaws are caused by design mistakes, some of the most devastatingflaws are caused by implementation mistakes. Design flaws and implementation flaws can compromise dataand can cause your software to misbehave. Attacks on implementation flaws can also sometimes cause yoursoftware 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 infrastructurethat might reasonably be attacked, but they do not identify specific ways in which those pieces might beattacked.

Therefore, when you implement your software, you must take steps to make it harder to compromise yourcode. 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 compilerfeatures that make your job easier.

Code HardeningCode 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, shoringup the stern of a ship to repair a leak, or hiding a ruler’s secrets so that he or she cannot be blackmailed intobecoming 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, passdata to the interpreters in a safe fashion.

To prevent command injection attacks in SQL queries, use parameterized APIs (or manually quote thestrings 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 decisionsbased 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, alongwith other code-hardening techniques.

Code SigningCode signing is a technology for ensuring the authenticity of executable code. By signing your code, theoperating system can verify that an app has not been modified by other software and can verify that updatesto 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 isrevisited in Cryptographic Services (page 23).

Principle of Least PrivilegeThe principle of least privilege states that a piece of code should, to the extent practical, run with exactly thepermissions it needs, and no more.

The closest analog in the physical world is designating certain areas for certain activities, and only allowingpeople to enter those areas if they have a legitimate need to perform those activities. At a conference, forexample, 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 arenecessary 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 iscritically important to regularly perform threat modeling as you add new code.

Code SecurityCode Signing


16

App SandboxingTo parents, a sandbox is a safe haven in which their children can play without needing to worry about themgetting hurt. It is a somewhat enclosed, safe environment, free from things that might injure them. And aslong 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 securityholes 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 ifthey get compromised.

To achieve this goal, a sandbox limits an app’s capabilities to match its expected behavior (as defined by theAPIs 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 crimeprevention program. If someone appears who is acting suspicious, the neighbors can take action. In a similarfashion, a sandboxed environment allows an app to do the things it normally would do. However, if it stepsout of line, the operation fails, and in some cases, the process is killed outright.

Privilege SeparationIn an ideal world, writing software according to the principle of least privilege would be straightforward; theuser would grant each process just enough privilege required to do a job, and no more. However, this approachcan 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 typicallyrequire 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 ratherbroad—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 endof the day.

In computers, the solution to this problem is privilege separation—breaking up a piece of software into multiplepieces so that each piece individually requires fewer capabilities and so that those capabilities are protectedfrom inappropriate use by other parts of the app, tool, or daemon. This separation between pieces is called atrust boundary .

For example, a word processor that accesses help files over a network might separate out the networkingportions into a separate help file downloader app. The main app should scrutinize the data sent back from thishelper, 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 SecurityApp Sandboxing


17

Important: The distrust between the helpers and the main app must be mutual. The networking helperin 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 networkinghelper 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 thebehalf of another piece of software. That helper, daemon, or agent may be sandboxed, unsandboxed, orprivileged.

● A sandboxed helper, daemon, or agent has fewer privileges than an ordinary app running as the user. Itmay still have more permissions than the calling app, however, because the caller may be in an evenstricter sandbox.

● An unsandboxed helper, daemon, or agent has the same privileges as the user. However, because thecalling app may be running in a sandbox, this unsandboxed helper may have more privileges than thecaller.

● A privileged helper, daemon, or agent runs as another user who has broader permissions (often as theroot 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 rolein making that environment more usable. For example, a privileged agent (privileged only because it isrunning outside the sandbox) is used by the OS to provide a number of services to sandboxed apps, suchas the powerbox, which displays an “open file” dialog on behalf of the app and then temporarily adds thechosen file to the app’s sandbox entitlements.

Because a differently privileged helper, daemon, or agent has the potential to allow its caller to significantlyviolate established privilege boundaries, it must be written in such a way that limits what its caller can do. Forexample, the powerbox allows an app to gain access to files outside the app’s container directory, but it doesso 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 singleapp. These helper apps can have different privileges than the main app. OS X v10.8 and later also provides theNSXPC API, which makes the process of privilege separation even more transparent by allowing the main appto remotely call a specified set of methods on specific objects in the helper app and vice versa.

Code SecurityPrivilege Separation


18

To Learn MoreFor 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 SecurityTo Learn More


19

Code security protects the normal, day-to-day operations of an app, tool, or daemon. But what happens whenyour code is under siege? It is often essential to know not only what the user is doing but also who the useris 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 processis called authentication .

In computer security, authentication verifies the identity of a user or service. Authentication usually serves oneof two purposes:

● As a precursor to authorization, identifying the requesting entity to determine whether that entity shouldhave permission to perform an operation

● For producing an audit trail by logging who performed an operation so that blame can be cast whensomething breaks

Three types of authentication are most common:

● Local user authentication. Verifying a user’s identity is usually performed by the operating system as thefirst step in authorization. If your code is running as a normal user, the operating system limits what yourcode can do based on that user’s permissions. Your code can also ask the operating system for the identityof 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 certaintasks. Authenticating a user remotely requires that your code send credentials in some form, such as apassword, a cookie, or a digital certificate.


20

Authentication and Authorization

AuthorizationAuthorization is the process by which an entity such as a user or a server gets permission to perform a restrictedoperation. The term is also often used to refer to the right itself, as in “The soldier has authorization to enterthe command bunker.”

The difference between authentication and authorization is somewhat subtle. Often, the mere fact that a userhas an account means that the user is authorized to do something, in which case authentication andauthorization 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 into 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 preventunauthorized use of the device. After entering this passcode, the user of the device is presumed to be authorizedto use the device. In addition, each app is digitally signed and can therefore be authenticated by the operatingsystem. 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 bootvolume.

● 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 loginscreen 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 turnperforms authentication and authorization.

To Learn MoreFor a more detailed conceptual overview of authentication and authorization in OS X, read Authentication,Authorization, and Permissions Guide .

Authentication and AuthorizationAuthorization


21


Authentication and AuthorizationTo Learn More


22

Cryptographic services form the foundation of securing data in transit (secure communications) and data atrest (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 andiOS provide to help you use cryptography in your own application.

Encryption and DecryptionEncryption is a means of protecting data from interception by transforming it into a form that is not readableexcept 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 acrossan untrusted communication channel, it is the responsibility of the two endpoints to use encryption to securethe communication. Similarly, when storing information on a local disk, an app may use encryption to ensurethat 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 servedifferent 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, asymmetricencryption, and steganography.


23

Cryptographic Services

Symmetric EncryptionIn symmetric encryption, a single key (usually a long string of random bytes) is used to mathematically transforma 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 knowthe same secret key, symmetric encryption is not sufficient by itself.

Asymmetric EncryptionIn 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 .

Cryptographic ServicesEncryption and Decryption


24

Note: Although the two keys are mathematically related, it is considered computationally infeasibleto derive one key from the other. The security of public key cryptography depends on this being thecase.

Asymmetric EncryptionPublic key

Ciphertext

Ciphertext

Plaintext Plaintext

PlaintextPlaintext

Private key

Private keyor

Public key

1001101011111010

100010

ABCDEFGHIJKLMNOP

QRSTUV

ABCDEFGHIJKLMNOP

QRSTUV

Cipher Cipher

1001101011111010

100010Cipher Cipher

Asymmetric encryption is often used for establishing a shared communication channel. Because asymmetricencryption is computationally expensive, the two endpoints often use asymmetric encryption to exchange asymmetric key, and then use a much faster symmetric encryption algorithm for encrypting and decrypting theactual 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.

SteganographySteganography means hiding information in less important bits of another piece of information.

Sender Receiver

Unencrypted Message

Steganography

to be ornot tobe thatis the

question

to be ornot tobe thatis the

question

Unencrypted MessageEncrypted Message

stovqtbexcorrtbnotlktowsqybefgthatpfwaismthevs

ewquestionla

EncryptionAlgorithm

DecryptionAlgorithm

Cryptographic ServicesEncryption and Decryption


25

Steganography is commonly used for storing copyright information into photographs in such a way that islargely indistinguishable from noise unless you know how to look for it.

Steganography can also be used for storing encrypted volumes underneath other encrypted or unencryptedvolumes (either by using the unused blocks or by taking advantage of error correction in subtle ways).

HashingA hash value, or hash, is a small piece of data derived from a larger piece of data that can serve as a proxy forthat 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 arespecifically 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 hometogether. One day, a bully intercepted the note and arranged for Bob to arrive ten minutes early so that hecould steal Bob’s lunch money. To ensure that their messages were not modified in the future, they deviseda scheme in which they computed the remainder after dividing the number of letters in the message by thesum 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 hashingalgorithms, collisions are unlikely if you make small changes to a piece of data. This tamper-resistant natureof good hashes makes them a key component in code signing, message signing, and various other tamperdetection schemes.

At a high level, hashing is also similar to checksumming (a technique for detecting and correcting errors intransmitted data). However, the goals of these techniques are very different, so the algorithms used are alsovery different. Checksums are usually designed to allow detection and repair of a single change or a smallnumber of changes. By contrast, cryptographic hashes must reliably detect a large number of changes to asingle 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 documentscited at the end of this chapter.

Cryptographic ServicesHashing


26

Signing and VerifyingA signature is a way to prove the authenticity of a message, or to verify the identity of a server, user, or otherentity.

In olden days, people sometimes stamped envelopes with a wax seal. This seal not only proved who sent themessage 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, signingand verifying require two pieces of information: the appropriate half of a public-private key pair and a digitalcertificate.

The sender computes a hash of the message and encrypts it with the private key. The recipient also computesa hash and then uses the corresponding public key to decrypt the sender’s hash and compares the hashes. Ifthey are the same, the data was not modified in transit, and you can safely trust that the data was sent by theowner 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 alsotrust 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 someoneelse, whose certificate is in turn signed by someone else, and so on, forming a chain of trust to a certificatethat the recipient inherently trusts, called an anchor certificate . This certificate may be a root certificate—aself-signed certificate that represents a known certificate authority and thus the root of the tree of certificatesoriginating from that authority—or it may be any arbitrary certificate that the user or application developerhas 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 definedby two factors:

● Each certificate can contain one or more certificate extensions that describe how the certificate can beused. For example, a certificate that is trusted for signing email messages might not be trusted for signingexecutable 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 stringcreated specifically for this purpose), a user or server can prove that he, she, or it is in possession of the privatekey 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.

Cryptographic ServicesSigning and Verifying


27

Secure StorageOS X and iOS provide a number of technologies for secure storage. Of these, the three most commonly usedtechnologies are keychains, FileVault, and data protection.

KeychainsIn concept, a keychain is similar to a physical key ring in that it is a place where keys and other similarly smallpieces of data can be stored for later use in performing cryptographic tasks, but the similarity ends there. Witha physical key ring, the owner can take the key and use it to unlock something. With a keychain, apps usuallydo 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 processcalled 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 keyring. You can ask that guard to unlock a door for you if you are authorized to enter, but you usually can’t unlockthe 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.

FileVaultIn 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 protectedonly a user’s home directory.)

FileVault and its configuration UI are described in more detail later, in End-User Security Features.

Data ProtectioniOS provides APIs that allow an app to make files accessible only while the device is unlocked to protect theircontents from prying eyes. With data protection, files are stored in encrypted form and are decrypted onlyafter 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 theuser shuts down the device.

Cryptographic ServicesSecure Storage


28

To Learn MoreFor a more detailed conceptual overview of authentication and authorization in OS X, read CryptographicServices Guide .

To learn more about creating signing certificates, read Creating Your Signing Certificates in App DistributionGuide .


Cryptographic ServicesTo Learn More


29

The OS X and iOS security implementation includes a daemon called the Security Server that implementsseveral security protocols, such as access to keychain items and root certificate trust management. OS X alsoincludes a separate per-user agent, called the Security Agent , that is used by the Security Server to display auser interface.

This appendix briefly describes their roles.

Security ServerThe Security Server (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 cryptographicservices on their behalf. Because developers generally use references to keys rather than using the keysthemselves, the Security Server can keep those keys in a separate address space from the client process, thusreducing the risk of accidental disclosure.

As an added advantage, whenever Apple introduces new authentication or encryption technology, existingsoftware that uses the OS X security APIs can transparently support it without code changes, provided thatthe 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 SecurityServer.

Security AgentThe Security Agent is a separate process that provides the user interface for the Security Server in OS X (notiOS). 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 auser name and password. The advantages of performing this action in a separate process are twofold. First, anapplication can obtain authorization without ever having access to the user’s credentials (username andpassword, for example). Second, it enables Apple to add new forms of authentication without requiring everyapplication to understand them.

The Security Agent requires that the user be physically present in order to be authenticated. Because thegraphical user interface elements can’t be used through a command-line interface such as the Terminal appor a secure shell (ssh) remote session, this restriction makes it much more difficult for a malicious user tobreach an app’s security.

Note: iOS security services do not provide an authentication interface. Thus, there is no need forthe Security Server to have a user interface, and as a result, iOS does not provide a Security Agent.

Security Server and Security AgentSecurity Agent


31

OS X and iOS have many built-in security features, including industry-standard digital signatures and encryptionfor 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 theuser’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 PreferencesSecurity system preferences in OS X let the user configure FileVault and control some aspects of authorizationon 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 UserInterfaces in Secure Coding Guide ). When this icon shows a closed lock, authorization is required before theuser can change the settings in this system preferences pane.

FileVault and Encrypted VolumesWhen the user turns on FileVault (see Figure B-1), OS X uses 128-bit AES encryption to encrypt everything onthe root volume (or everything in the user’s home folder prior to OS X v10.7).

End-User Security FeaturesSecurity System Preferences


33

The system automatically decrypts files upon access if an authorized user is logged in, but the files remainencrypted 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 userwants to securely store files somewhere other than a FileVault-protected volume (such as on an external harddisk or removable media), the user can create an encrypted disk image.

For more information about FileVault, see Apple Knowledge Base Article HT4790.

Accounts System PreferencesWhen 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 theAccounts system preferences panes to add new users to the system.

End-User Security FeaturesAccounts System Preferences


34

http://support.apple.com/kb/HT4790

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

End-User Security FeaturesAccounts System Preferences


35

If the new user is not a member of the admin group, the administrator can limit the system features and appsto 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 AccessKeychain Access is an OS X utility that lets users see and modify the passwords, certificates, and other data thatare 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

End-User Security FeaturesKeychain Access


36

● See which certificates are available for use by email and web apps, who owns each certificate, and whoissued 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 Servicesprompts the user for a password.

In addition, the Keychain Access menu includes items to open the Certificate Assistant and Kerberos TicketViewer utilities. The Certificate Assistant enables users to create certificates, request certificates from a certificateauthority, create a public/private key pair, or evaluate a certificate. The Kerberos Ticket Viewer lets users seeany Kerberos tickets in use on the system, and enables them to renew or destroy a ticket, or change a ticket’spassword. Kerberos is described in more detail in Authentication, Authorization, and Permissions Guide .

MailApple’s Mail app and other email apps can extract a public key from the signing certificate of any signed emailand use it to encrypt messages sent to the owner of that key. See Digital Signatures in Cryptographic ServicesGuide for more information about digital signatures, and see Help in the Mail app for details on sendingencrypted email.

End-User Security FeaturesMail


37

Now that you’ve read about the basics, there are a few more things you should learn. First, read these twodocuments:

● App Sandbox Design Guide tells you the things you need to know about designing code to run in asandboxed 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 alsodescribes 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 documentexplains 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 DocumentationHere are a few other Apple documents you might be interested in, depending on what technologies you wantto learn more about.

Authentication and Authorization

● Authentication,Authorization,andPermissionsGuide provides additional information about authenticationand authorization at a conceptual level. (OS X only)

● Authorization Services Programming Guide and Authorization Services C Reference explain how to performcertain 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 orobtain information about a user. (OS X only)

● Security Interface Framework Reference describes the Objective-C interface to Authorization Services. Thisinterface 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. (OSX only)

Cryptography


38

Other Security Resources

● Cryptographic Services Guide describes encryption, decryption, signing, verifying, digital certificates, andother related concepts in more detail at a conceptual level.

● Security Transforms Programming Guide and Security Transforms Reference describe the preferred OS XAPI for most cryptographic tasks. (OS X only)

● Certificate, Key, and Trust Services Programming Guide and Certificate, Key, and Trust Services Referenceexplain how to work with certificates, keys, and other related technologies in more detail.

Code And Application Signing

● Cryptography Concepts In Depth inCryptographic ServicesGuide explains code signing concepts in greaterdepth.

● Creating Your Team’s Signing Certificates in Developing for the App Store shows you how to set up codesigning in Xcode.

● Code Signing Guide tells you how to perform code signing on the command line and other unusualsigning-related tasks.

Secure Storage

● KeychainServicesProgrammingGuide andKeychainServicesReference explain how to use the OS X keychainin your code.

● Advanced App Tricks in iOS App Programming Guide explains how to use the iOS data protection featurein your app. (iOS only)

Secure Networking

● CFNetwork ProgrammingGuide andURL Session ProgrammingGuide explain how to make secure networkconnections using high-level APIs.

● Secure Transport Reference tells how to make secure network connections at the socket layer. (OS X only)

Privilege Separation

● Designing Secure Helpers and Daemons in Secure Coding Guide provides guidance on how to securelyperform privilege separation.

● Daemons and Services ProgrammingGuide describes XPC services, which is the preferred way of launchingand communicating with helper apps in a sandboxed environment. (OS X only)

Miscellaneous

Other Security ResourcesOther Apple Documentation


39

● Apple's Open Source website provides Apple’s open source security code. You can examine it to see whichsecurity protocols and algorithms are supported by Apple’s OS X and iOS security implementation and tofind additional documentation.

● The Security topic areas in the OS X Developer Library and the iOS Developer Library contain a numberof security-specific release notes.

Third-Party DocumentationThere are a number of excellent books on computer security that you should consider reading. Here are justa 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 SocketsNetworking 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.

Other Security ResourcesThird-Party Documentation


40

http://www.opensource.apple.com/

● McKusick, Marshall Kirk, Keith Bostic, Michael Karels, and John Quarterman. The Design andImplementation of the 4.4 BSD Operating System . Addison-Wesley. 1996.

Standards and Protocol ReferencesThe following pages describe some of the standards, protocols, and algorithms used by Apple. Although manyof 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 CommonCriteria 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 Xserver.

Other Secure Networking Protocols

● The authentication model for HTTP is described in RFC 2617, HTTP Authentication: Basic and Digest AccessAuthentication .

● 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 Instituteof Standards and Technology (NIST) website.

Other Security ResourcesStandards and Protocol References


41

http://www.commoncriteriaportal.org/

http://www.niap-ccevs.org/cc-scheme/

http://web.mit.edu/kerberos/

http://www.apple.com/server/documentation/

http://www.ietf.org/rfc/rfc2617.txt

http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00

http://www.ietf.org/html.charters/tls-charter.html

http://tools.ietf.org/html/rfc5246

http://csrc.nist.gov/CryptoToolkit/aes/rijndael/

http://csrc.nist.gov/CryptoToolkit/aes/rijndael/

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 enhancedthe 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 accesscontrol lists (ACLs). Changed "Rendezvous" to "Bonjour."

2005-04-29


42

Document Revision History

NotesDate

New document that introduces computer security concepts and describesthe 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 anyform or by any means, mechanical, electronic,photocopying, recording, or otherwise, withoutprior written permission of Apple Inc., with thefollowing exceptions: Any person is herebyauthorized to store documentation on a singlecomputer or device for personal use only and toprint copies of documentation for personal useprovided that the documentation containsApple’s copyright notice.

No licenses, express or implied, are granted withrespect to any of the technology described in thisdocument. Apple retains all intellectual propertyrights associated with the technology describedin this document. This document is intended toassist application developers to developapplications only for Apple-branded products.

Apple Inc.1 Infinite LoopCupertino, CA 95014408-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 ofCisco in the U.S. and other countries and is usedunder license.

UNIX is a registered trademark of The OpenGroup.

APPLE MAKES NO WARRANTY OR REPRESENTATION,EITHER EXPRESS OR IMPLIED, WITH RESPECT TO THISDOCUMENT, ITS QUALITY, ACCURACY,MERCHANTABILITY, OR FITNESS FOR A PARTICULARPURPOSE. AS A RESULT, THIS DOCUMENT IS PROVIDED“AS IS,” AND YOU, THE READER, ARE ASSUMING THEENTIRE RISK AS TO ITS QUALITY AND ACCURACY.

IN NO EVENT WILL APPLE BE LIABLE FOR DIRECT,INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIALDAMAGES RESULTING FROM ANY DEFECT, ERROR ORINACCURACY IN THIS DOCUMENT, even if advised ofthe possibility of such damages.

Some jurisdictions do not allow the exclusion ofimplied warranties or liability, so the above exclusionmay not apply to you.

security overview 2

Science