|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "Security Fusings"
m |
m |
||
| (7 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| + | iDevice security and APTicket configuration settings are often determined by security fuses on the SoC. |
||
| − | A common misconception is that all [[iDevice|iDevices]] enforce certain flags in their bootloaders when certain "fuses" are "blown". |
||
| − | == |
+ | == Effective vs. Raw fusing == |
| − | Processor security flags are enforced by pulling several pins on the BGA low or high depending on the state of security needed. The same is done for board configuration. For example, the device security state is set to 0000 by removing all resistors. This is the PVT configuration. |
||
| + | iDevices have two views of fuses, the "raw" fuse status which represent the actual state of the fuses, and the "effective" fusing status, which is a copy of the raw fuses loaded into SoC registers that can override security configuration normally determined by the fuses, assuming one can write to the effective fusing status register. |
||
| − | == Board Identifiers == |
||
| − | Board identifiers are enforced by pulling several pins on the BGA low or high depending on the state of security needed. For example, the device configuration [[n94ap]] is set by pulling the pins to set the board ID: "0b1000" or 0x8. This measure saves costs by allowing Apple to reuse the same processor die with a specified ECID, but they can change the motherboard if necessary. |
||
| − | == |
+ | === Pre-A7 devices === |
| + | |||
| − | These so-called "fuses" are actually fixed resistors on the motherboard. |
||
| + | Pre-A7 devices only had one view of fuses, which could be overridden. However, production-fused devices have the security epoch set while development-fused devices don't, so that one can distinguish a production-fused device from a demoted device. |
||
| + | |||
| + | === Post-A7 devices === |
||
| + | |||
| + | Post-A7 devices have two views of fuses, effective and raw, and the AP and SEP can read both to distinguish a demoted device from a development-fused one. |
||
| + | |||
| + | == ECID == |
||
| + | |||
| + | See [[ECID]]. |
||
| + | |||
| + | == Production Mode == |
||
| + | |||
| + | The production mode fuse in the SoC controls whether JTAG/SWD is enabled on the AP or not as well as what UID/GID keys the AP AES engine will use to decrypt data. |
||
| + | |||
| + | == Security Mode == |
||
| + | |||
| + | The secure mode fuse controls whether JTAG/SWD is enabled on the SEP, and controls the GID/UID used by the SEP AES engine. It also governs whether the AP SecureROM can boot untrusted code on post-A7 devices, in addition to the Test Mode board configuration setting. From an AP perspective, the secure mode fuse is always read from the raw fuses. |
||
| + | |||
| + | |||
| + | == Fuse seal == |
||
| + | |||
| + | Unclear as to what the fuse seal does, though from the name it seems to lock the raw fuses from being altered further. Only present on post-A7 devices. |
||
| + | |||
| + | == Fuse lock == |
||
| + | |||
| + | Fuse locking sets a lock register such that changes to the effective fuses are no longer possible until the next device reset. This ensures that the only way to demote a device is to have a validly signed APTicket loaded by SecureROM. (assuming no vulnerabilities) |
||
| + | |||
| + | == Use in APTickets == |
||
| + | |||
| + | The Apple signing server uses the raw and effective production/security status to ensure that iOS builds are only being signed for devices that are expected to have them. |
||
| + | |||
| + | |||
| + | == Demotion == |
||
| + | |||
| + | Demotion is the term used to refer to changing a device's effective fuse status to enable debugging of the AP and SEP. The effective fuse status register will accept writes (assuming it hasn't been locked) to change the effective fuse status. For example, a production, secure fused device can be demoted to development and insecure by changing the effective fuse status register. AP can only change production mode, and SEP can only change secure mode. By default, this is only done when DPRO and DSEC are present in the APTicket. |
||
Latest revision as of 19:38, 5 December 2022
iDevice security and APTicket configuration settings are often determined by security fuses on the SoC.
Contents
Effective vs. Raw fusing
iDevices have two views of fuses, the "raw" fuse status which represent the actual state of the fuses, and the "effective" fusing status, which is a copy of the raw fuses loaded into SoC registers that can override security configuration normally determined by the fuses, assuming one can write to the effective fusing status register.
Pre-A7 devices
Pre-A7 devices only had one view of fuses, which could be overridden. However, production-fused devices have the security epoch set while development-fused devices don't, so that one can distinguish a production-fused device from a demoted device.
Post-A7 devices
Post-A7 devices have two views of fuses, effective and raw, and the AP and SEP can read both to distinguish a demoted device from a development-fused one.
ECID
See ECID.
Production Mode
The production mode fuse in the SoC controls whether JTAG/SWD is enabled on the AP or not as well as what UID/GID keys the AP AES engine will use to decrypt data.
Security Mode
The secure mode fuse controls whether JTAG/SWD is enabled on the SEP, and controls the GID/UID used by the SEP AES engine. It also governs whether the AP SecureROM can boot untrusted code on post-A7 devices, in addition to the Test Mode board configuration setting. From an AP perspective, the secure mode fuse is always read from the raw fuses.
Fuse seal
Unclear as to what the fuse seal does, though from the name it seems to lock the raw fuses from being altered further. Only present on post-A7 devices.
Fuse lock
Fuse locking sets a lock register such that changes to the effective fuses are no longer possible until the next device reset. This ensures that the only way to demote a device is to have a validly signed APTicket loaded by SecureROM. (assuming no vulnerabilities)
Use in APTickets
The Apple signing server uses the raw and effective production/security status to ensure that iOS builds are only being signed for devices that are expected to have them.
Demotion
Demotion is the term used to refer to changing a device's effective fuse status to enable debugging of the AP and SEP. The effective fuse status register will accept writes (assuming it hasn't been locked) to change the effective fuse status. For example, a production, secure fused device can be demoted to development and insecure by changing the effective fuse status register. AP can only change production mode, and SEP can only change secure mode. By default, this is only done when DPRO and DSEC are present in the APTicket.
