How was the security chip 'Secure Enclave' of Apple terminals broken through?

There is a non-patchable vulnerability in ' Secure Enclave (SEP) ' used to encrypt sensitive data on Apple devices, announced by windknown belonging to Chinese hacker group ' Pangu ' at MOSEC 2020 .. A document summarizing information about this vulnerability is published on GitHub, and you can know the details of the vulnerability such as extracting the encryption key of the virtual memory space.

presentations/Attack_Secure_Boot_of_SEP.pdf at master · windknown/presentations · GitHub

Built into almost every Apple device, the Secure Enclave is designed to enable file encryption, as well as passwords, credit cards used in Apple Pay, and biometrics such as Touch ID and Face ID. A chip that also stores keys etc. There was concern that a non-patchable vulnerability could be found in the chip, which could allow a third party to gain full access to your passwords and credit card information.

Patch unrecoverable vulnerability found in ``Secure Enclave'' chip responsible for security of Apple terminals-GIGAZINE

In order to understand the mechanism of attacking the Secure Enclave, it is necessary to know the iOS boot flow. In the boot of iOS, 'AP space' where

iBoot that starts a normal OS is performed and 'SEP space' where 'SEPOS' is started by the Secure Enclave are separated. As for the IMG4 file that is expanded on the memory at startup, different files are read in the AP space and SEP space, and the normal OS is started in AP space and SEPOS is started in SEP space.

The Secure Enclave is a chip with 4096 bytes of RAM, and it is possible to access the 'mailbox' and shared memory for power management and interrupt drive from the AP space. Confidential information such as password entered from AP space is encrypted by Secure Enclave device unique value (UID).

The conversion table of virtual memory and physical memory of Secure Enclave looks like this.

Of the memory area of the conversion table, 'Mapped IO registers' can be read and written from both SEP space and AP space. The SEP space and AP space send and receive data via Mapped IO registers, which act as mailboxes. The base address of Mapped IO registers in AP space is '0x2_0DA0_4000', and the base address in SEP space is '0xCDA0_0B80 (0x2_0DA0_0B80 in physical memory)'. The message table sent and received by Mapped IO registers is as follows.

Each message contains 4 bytes of data, a list of that data is below. Of these, 'Boot TZ0' is the data sent from the AP space to allocate the external RAM area to the Secure Enclave and secure the memory capacity necessary for booting SEPOS. It is important in this vulnerability regarding Secure Enclave. is.

Before performing Boot TZ0, it is necessary to set the three registers 'Base', 'End' and 'Lock' in the AP space. The memory address where the register is set differs depending on the generation of the processor, and the correspondence table is as follows.

The memory area allocated to the Secure Enclave is encrypted with a 24-byte key whose value changes each time it is booted, and can be used

transparently from the Secure Enclave ROM and SEPOS without being aware of encryption. The AES key by the AES-256-XEX method is generated for each ROM and SEPOS of the Secure Enclave, and the key used to decrypt the encrypted data is different. Since a message authentication code (MAC) based on encryption is required, the memory capacity that can actually be used will be halved.

However, the Secure Enclave does not encrypt all memory areas. The area starting from '0x8_00BF_0000' and '0x8_00BF_F000' is not encrypted.

After setting the TZ0 register, allocating memory, and completing encryption, the Secure Enclave expands the IMG4 file on memory and starts SEPOS. SEPOS creates the AES key to access the encrypted memory space and loads the Secure Enclave firmware to complete the startup on the SEP space side.

Based on the above structure of encryption by the Secure Enclave, attacks on the Secure Enclave include 'remove separation of memory space', 'extract AES key from unencrypted memory area', and 'AP space and SEP space'. It will be possible to extract data by 'competing cache with'.

First, the memory area is shared between the AP space and SEP space. The code of AP space can be modified by '

Checkm8 ', so when setting the TZ0 register, the start address is offset by '0x10_0000'. This operation seems to release the separation of AP space and SEP space.

You can now refer to the memory area of SEP space from AP space, but the memory area of SEP space is encrypted and cannot be read as it is. The area that is used here is the area that begins with '0x8_00BF_0000' and '0x8_00BF_F000', which is not encrypted even in the SEP space. By operating the virtual address mapping and changing the code to read the area starting from '0x8_00BF_0000' and '0x8_00BF_F000', it is possible to extract the AES key for SEP ROM generated at boot time. Finally, by competing the cache of the AP space processor and the cache of the SEP space and extracting the AES key for SEPOS, it becomes possible to dump the data encrypted by the Secure Enclave.

All the vulnerabilities this time can be used for A8/A9 processors, and some vulnerabilities can be used for A7/A10 processors. 'I'm looking forward to seeing how to exploit this vulnerability,' said windknown, who announced the vulnerability.

in Mobile,   Software,   Hardware,   Security, Posted by darkhorse_log