4. iOS Security Architecture
• Hardware Security
• Secure Boot
• Code Signing
• Sandbox
• Encryption and Data Protection
• General Exploit Mitigations
4
5. Hardware Security
The iOS security architecture makes good use of hardware-based security
features that enhance overall performance. Each iOS device comes with
two built-in Advanced Encryption Standard (AES) 256-bit keys. The
device’s unique IDs (UIDs) and a device group IDs (GIDs) are AES 256-bit
keys fused (UID) or compiled (GID) into the Application Processor (AP) and
Secure Enclave Processor (SEP) during manufacturing. There's no direct
way to read these keys with software or debugging interfaces such as
JTAG. Encryption and decryption operations are performed by
hardware AES crypto-engines that have exclusive access to these
keys.
The GID is a value shared by all processors in a class of devices used to
prevent tampering with firmware files and other cryptographic tasks not
directly related to the user's private data.
UIDs, which are unique to each device, are used to protect the key
hierarchy that's used for device-level file system encryption.
5
6. Secure Boot
https://varunsavy.wordpress.com/ios-platform/
The Boot ROM contains immutable
code and the Apple Root CA
If any of these steps fail, the boot
process will terminate immediately and
the device will enter recovery mode and
display the "Connect to iTunes" screen.
6
8. Code Signing
Apple has implemented an elaborate DRM (Digital Rights
Management) system to make sure that only Apple-approved
code runs on their devices, that is, code signed by Apple. In
other words, you won't be able to run any code on an iOS
device that hasn't been jailbroken unless Apple explicitly
allows it.
8
10. General Exploit Mitigations
iOS implements address space layout randomization (ASLR) and eXecute Never (XN) bit to
mitigate code execution attacks.
ASLR randomizes the memory location of the program's executable file, data, heap, and
stack every time the program is executed. Because the shared libraries must be static to be
accessed by multiple processes, the addresses of shared libraries are randomized every time
the OS boots instead of every time the program is invoked. This makes specific function and
library memory addresses hard to predict, thereby preventing attacks such as the return-to-
libc attack, which involves the memory addresses of basic libc functions.
The XN mechanism allows iOS to mark selected memory segments of a process as non-
executable. On iOS, the process stack and heap of user-mode processes is marked non-
executable. Pages that are writable cannot be marked executable at the same time. This
prevents attackers to execute machine code injected into the stack or heap.
10
12. Apps on iOS
iOS apps are distributed in IPA (iOS App Store Package) archives. The IPA file is a ZIP-compressed archive that
contains all the code and resources required to execute the app.
IPA files have a built-in directory structure. The example below shows this structure at a high level:
• /Payload/ folder contains all the application data. We will come back to the contents of this folder in more detail.
• /Payload/Application.app contains the application data itself (ARM-compiled code) and associated static
resources.
• /iTunesArtwork is a 512x512 pixel PNG image used as the application's icon.
• /iTunesMetadata.plist contains various bits of information, including the developer's name and ID, the bundle
identifier, copyright information, genre, the name of the app, release date, purchase date, etc.
• /WatchKitSupport/WK is an example of an extension bundle. This specific bundle contains the extension delegate
and the controllers for managing the interfaces and responding to user interactions on an Apple Watch.
12
13. IPA Payloads
• MyApp: The executable file containing the compiled (unreadable) application source code.
• Application: Application icons.
• Info.plist: Configuration information, such as bundle ID, version number, and application
display name.
• Launch images: Images showing the initial application interface in a specific orientation.
The system uses one of the provided launch images as a temporary background until the
application is fully loaded.
• MainWindow.nib: Default interface objects that are loaded when the application is launched.
Other interface objects are then either loaded from other nib files or created
programmatically by the application.
• Settings.bundle: Application-specific preferences to be displayed in the Settings app.
• Custom resource files: Non-localized resources are placed in the top-level directory and
localized resources are placed in language-specific subdirectories of the application bundle.
Resources include nib files, images, sound files, configuration files, strings files, and any
other custom data files the application uses.
13
14. App Permissions
Starting with iOS 10.0, apps must include usage description keys for the types of permissions
they request and data they need to access
Contacts
Microphone
Calendars
Camera
Reminders
HomeKit
Photos
Health
Motion activity and fitness
Speech recognition
Location Services
Bluetooth sharing
Media Library
Social media accounts
14
16. iOS Application Attack
surface
Validate all input by means of IPC communication or URL schemes, see also:
Testing Custom URL Schemes
Validate all input by the user in input fields.
Validate the content loaded inside a WebView, see also:
Testing iOS WebViews
Determining Whether Native Methods Are Exposed Through WebViews
Securely communicate with backend servers or is susceptible to man-in-the-middle (MITM)
attacks between the server and the mobile application, see also:
Testing Network Communication
iOS Network APIs
Securely stores all local data, or loads untrusted data from storage, see also:
Data Storage on iOS
Protect itself against compromised environments, repackaging or other local attacks, see also:
iOS Anti-Reversing Defenses
16
17. Testing Custom URL
Schemes
URL schemes offer a potential attack vector into your app, so
make sure to validate all URL parameters and discard any malformed
URLs. In addition, limit the available actions to those that do not risk
the user’s data.
For example, do not allow other apps to directly delete content or
access sensitive information about the user. When testing your
URL-handling code, make sure your test cases include improperly
formatted URLs.
17
19. Testing iOS WebViews
WebViews are in-app browser components for displaying interactive web content. They can
be used to embed web content directly into an app's user interface. iOS WebViews support
JavaScript execution by default, so script injection and Cross-Site Scripting attacks can affect
them.
19
20. Determining Whether Native Methods
Are Exposed Through WebViews
20
Since iOS 7, Apple introduced APIs that allow communication
between the JavaScript runtime in the WebView and the native
Swift or Objective-C objects. If these APIs are used carelessly,
important functionality might be exposed to attackers who
manage to inject malicious scripts into the WebView (e.g.,
through a successful Cross-Site Scripting attack).
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06h-Testing-Platform-Interaction.md#determining-whether-native-methods-are-exposed-through-webviews-mstg-platform-7
40. Apple extends deadline for new HTML5
App Store guidelines to March 2020
https://developer.apple.com/app-store/review/guidelines/#third-party-software
https://9to5mac.com/2019/09/06/apple-extends-deadline-for-new-html5-app-store-guidelines-to-march-2020/
40