IOS security mechanism

The introduction

During development, there are a number of common problems:

• App structure cannot run after modification
• Other applications cannot be read directly
• The program runs at a different address every time
• An upgraded system cannot degrade

With these questions in mind, let’s take a look at the security mechanisms provided by iOS.

IOS security architecture

This is apple’s official iOS security architecture. It is divided into two parts. The first part is the hardware and firmware layer, which provides security protection. The second part is the security provided by the software.

As you can see, above the hardware layer, it has an encryption engine that encrypts our device key, master key, and Apple root certificate. In addition to the encryption engine, it also has a module for Secure Enclave, which is used for encryption and decryption, and our Touch ID stores the user’s fingerprint password.

Again look up his software layer partition with a user, the user is fully encrypted partition, and the encryption function can’t be closed, apple’s encryption engine is hardware level, all in and out of storage data are encrypted by apple encryption engine, and the encryption engine for encryption key is associated with the hardware. So I can’t take encrypted data from one device and decrypt it from another device. It won’t work.

Finally, the application sandbox provides a security mechanism for a data protection class that can protect the security of our application data. For example, the data we write to the app sandbox can only be accessed after the user unlocks the device through the data protection class.

Next, we will understand the iOS system security architecture from the aspects of secure startup chain system, application code signing, sandbox mechanism, ROP, ASLR, encryption and data protection.

Safety start chain system

At each step of the startup process, components are signed by Apple and can only be executed after the signature is verified. Let’s take a look at the system Boot process. There is a code fragment called Boot ROM integrated in iOS devices. This code is burned to a piece of memory in the processor and is read-only. If it passes validation, the underlying boot loader verifies the boot loader, and if the boot loader also passes validation, the kernel is loaded. There will be signature verification in each of the procedures mentioned above. If one part finds that signature verification fails, it will enter recovery and firmware upgrade mode.

The system software licensing mechanism is designed to prevent the device from being downgraded to an earlier version that lacks the latest security updates. IOS uses a mechanism called system software licensing, which is explained by the process of swiping firmware onto the phone.

Our firmware is going to be flushed to the phone by the CPU, and the CPU will have iTunes send our firmware signature to the server before writing our firmware, and it will return if the server has enabled authentication. Verification license or verification license plus a random string, when we get the verification license, we can pass the verification, and the CPU will actually brush our firmware onto the phone.

If Apple turns off validation, in earlier versions we could trick the CPU into writing our firmware by saving SHSH if only one validation license was returned. However, in later versions, apple returned a random string, which is hardware dependent and can only be used once, to ensure that the numbers cannot be simulated, so it was useless to save SHSH.

Application code signature

Application code signing is to ensure that all applications are consistent to source, and has not been tampered with, iOS requires all executable code is signed by apple certificate issued, including our executable programs, the inside of the code or the code to load dynamic libraries, as well as the load of resources, so the executable code and dynamic library, When we run, there will be a signature verification, only after the verification can run properly.

Sandbox mechanism

IOS also provides a sandbox mechanism to ensure that all of our running applications are in a sandbox module. From the above figure, we can see that when we install an application, it runs in an isolated environment. Each application is an isolated environment, and does not interfere with each other, nor can it access the data of other applications at will. So the sandbox has several characteristics:

• Each application has its own storage space;
• Applications cannot directly access the stored content of other programs. For example, it can’t read other app files or content;
• All data requested by the application passes permission detection. The requested data here is data like text messages, photos, etc., and if our application wants to access that data, it will pass a permission check and let the user decide whether or not to allow you to access that data;

ROP

The processor can tell which part of memory is executable code and which part of memory is data, and it doesn’t allow data to be executed, only code to be executed. So let’s look at a simple example. Suppose this is a target program, it is above the data section, below is the code, if we write malicious code as data to the data section, he is unable to execute, only in the code section can be executed, in the data section of the content is unable to execute.

We can use ROP to create a block of writable executable memory time. First we to explain what is ROP, is equivalent to our program in different parts of the code snippets together, through a to execute the instruction process, to achieve our ultimate goal, so if we create a writeable through ROP executable memory areas, to write our own some code, But these codes are written by ourselves, and they are not signed. At this time, the function of code signature is reflected, and they will not allow the execution of this code. Of course, we can just connect some code fragments of the target through ROP to perform some functions we want.

ASLR

Take a look at the address space layout randomization feature, which is also used to prevent ROP attacks. For ROP attack must know the address of a specified code snippet to get what we want, and then to perform, then the address space of the randomization, that is to say in binary files, library files, dynamic library file and the location of the stack memory address is random, we put these files loaded into memory, it loads the base address is changing every time. We can view the base addresses of the modules loaded in our application with the command image list -o -f.

Here is a simple Demo we wrote. We will set a breakpoint at the entry of the program execution:

Then, let the program run. After running, it will break at this breakpoint, at which point we use the previous command to check the module loaded and its address. As you can see, the base address for the executable file load is ef9e000.

If we run the command again and look at the module it loaded, we see that the base address of the executable is changed to 2f1e000, so every time it loads, its address is random.

In the experiment we just did, we saw that when our executable program was loaded, its base address changed every time it was loaded into memory.

Encryption and data protection

The contents of our files are encrypted with the file key, which, of course, is encrypted with the class key and is stored in the file element. The original file data is encrypted by the file system key, so if we want to read the contents of a file, the encrypted file can be decrypted only if both the hardware and the password key are possessed. If we put the encrypted file contents on other hardware to decrypt, it will not decrypt correctly because the hardware key is different on each device. If the user does not enter the password key, the contents of the file cannot be decrypted. Of course, here we see a file system key, this file system key can achieve the function of fast erase, as long as we delete the file system key, then all files are not accessible, so we can quickly erase the device data.

conclusion

• The security startup chain of security startup will ensure that the system we start is trusted when the system is started.
• System software licensing mechanism, which can ensure that our system can not revert to the original old version after updating;
• Application code signature, all running code must be signed by Apple to run;
• Run time security, there are three main points: first, sandbox mechanism, Apple provides sandbox mechanism, let us run in the sandbox. Another is data execution protection, which can distinguish between what is data and what is code, which can only work if data doesn’t work. Finally, the address space layout is randomized. Every time the program is loaded, its base address is randomly changed.
• Apple provides data encryption protection classes to protect the security of data in our apps.

Although iOS system provides a lot of security guarantees to ensure the security of our applications, there are still many problems. In XcodeGhost before problems, for example, because developers use third-party development tools, and third-party development tools in the embedded malicious code, so cause we are in the written application of the malicious code to write directly to our application, also can’t detect system, because all of the code are after signature verification, And it runs in the system.

In addition to the hazards of third-party tools, jailbreaking can also compromise the security of iOS itself. After jailbreaking, many iOS system permissions will be broken, we can directly run some of our applications with root permissions, so we can read some files of the system at will.