iOS is one of the most popular operating systems available today. One of the most commonly mentioned preeminent features of this operating system is the security (or rather, fewer security attacks that occur). So to get this great feature, what has iOS applied in its operating system? In this article I will help you generalize the main applications that are applied to the security structure of this operating system
I. Models of iOS security structure
As can be seen from the image above, each app will be run in its own sandbox. Including a data security layer (Data protection class). The sandbox will linger in the user’s partition. Data in this region will be subject to iOS’s encryption algorithms. This partition is part of the file system next to the operating system partition. In addition, the hardware and firmware security of iOS is also very focused. As with the use of secure enclaves and secure elements in the kernel, crypto engines – the only things that can access the system’s encryption keys. Along with that, the deepest of the system will be the device keys and group keys will talk about at the end with Apple’s root certificate (Apple Root Certificate).
II. Hardware security
As mentioned above, each iOS device will have 2 AES-256-bit encryption keys built-in, the device ID (UID) and the device group ID (GID). These two key IDs will be attached to Application Processor (AP) and Secure Enclave Processor (SEP) right from the manufacturing process. These keys can only be read from the crypto engine.
The GID is a shared value between processors of the same device class, used to prevent tampering with firmware files and to prevent other encryption tasks from accessing user information. Meanwhile, the UID is a unique value for each device, used to protect the system key in encrypting system files at the device level. UID values were not recorded during the manufacturing process, so Apple could not recover. (That’s as Apple says).
III. Secure Boot
First when booting the iOS system, the system will call to the Boot ROM , which contains the code can not be fixed as well as Apply CA (Attached in a silicon chip). Next, if the signature of the Low Level Bootloader (LLB) is correct, it is the LLB’s turn to check the signature of the iBoot bootloader . If correct, the next job will transfer to the iOS kernel. If it fails at a certain step, the boot process will immediately be canceled and transferred to revorery mode , where the words “Connects to iTunes”. However, if the Boot ROM fails to boot, the system’s last attempt will be to call the Device Firmware Upgrade (DFU) to reset the system’s original state.
The above process is called Secure Boot Chain with the participation of kernel, kernel extensions, bootloader and baseband firmware. Its purpose is to ensure the integrity of the boot process, make sure the system and components are written and distributed by Apple.
IV. Code Signing
Apple has implemented a complex DRM system with the sole purpose that only devices signed by Apple can run on Apple devices. The purpose of this is so that users can only install applications through the Apple app store. It can be said that iOS is a magnificent crystal prison for users of this system.
In addition, Apple certified developers can run the application. Developers will have to attend an Apple developer training program and pay an annual fee for this. There are also free accounts that allow compile and deploy applications, but not uploaded to the App Store. On jailbroken devices, applications can also be installed via sideloading. (Details can be found in his article here )
V. Encryption and data protection
Apple uses an algorithm called Fairplay Code Encrypting. Basically, it was developed as a DRM for paid multimedia content via iTunes. It was originally used for MPEG and QuickTime streams, but can also be used for executable files. The basic rule will look like this: When a user registers an Apple ID, Apple creates a set of public / private keys, in which the private key is stored securely in the user’s device. When users download an application, it will be encrypted with the public key and decrypted on memory when running RAM). Because the private key is stored on the user’s computer, only devices associated with the account can run the application.
Apple used encryption on hardware and firmware right from the 3GS generation. Each device has hardware encryption based on the AES-256 and SHA1 algorithms. In addition, each device will have a UID attached to the Application Processor (AP). This UID is not stored anywhere else and is not accessible (except for encryption engines).
BECAUSE. Sandbox
Sandbox is a core feature of iOS security. It ensures that applications will run with mobile permissions and that only very few applications can run with root . An application will reside in one container, which stipulates that it only has access to the file it owns, as well as certain APIs. Access to resources such as files, network sockets, IPC or shared memory will be controlled by the sandbox. The mechanism is as follows:
- The application can only be run in the directory it was granted (
(/private)/var/containers/Bundle/Application) through a chroot-like process. - The syscall
mmapandmprotectbeen slightly modified to prevent the application from attempting to create executable areas in memory as well as stopping processes generated from source code. - All processes are independent of each other.
- Unable to directly access hardware drivers but through the Apple framework.
VII. Other general restrictive mechanisms
iOS also uses address space layout randomization (ASLR) and eXecute Never (XN) to limit code execution attacks.
ASLR will generate random addresses for executable files, data, heap and stack each time. Because libraries need access from multiple processes, the address will be randomly generated at device startup. This will make the address of processes very difficult to guess, limiting execution attacks as well as return-to-lib attacks.
XN is a mechanism to mark an area on memory as impossible to execute. In iOS, the heap and stack of user processes will be highlighted. Pages labeled with writable cannot be executable at the same time. This helps limit the execution of machine code on the heap and stack.
summary
The above is a brief description of the security mechanisms of an iOS system. It can be said that Apple has applied a lot of solutions to ensure the safety of the system and its users. However, every system has its own flaws and Apple always welcomes community findings for iOS vulnerabilities to promptly fix and improve it. If by chance one day you find out that there are vulnerabilities in these security mechanisms, don’t hesitate to report it to Apple.