Difference between revisions of "Security Fusings"

From The iPhone Wiki
Jump to: navigation, search
(Fuse seal)
(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".
 
   
== Processor Security ==
+
== 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 that can override security configuration normally set by the fuses, assuming one can write to the effective fusing status register.
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.
 
   
  +
=== Pre-A7 devices ===
For example, the device security state is set to 0000 by removing all resistors. This is the PVT configuration.
 
   
  +
Pre-A7 devices only had one view of fuses and it could have overrides enabled. 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.
== Board Identifiers ==
 
   
  +
=== Post-A7 devices ===
Board identifiers are enforced by pulling several pins on the BGA low or high depending on the state of security needed.
 
   
  +
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.
For example, the device configuration [[N94ap|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.
 
   
== "Fuses" ==
+
== ECID ==
   
  +
See [[ECID]].
These so-called "fuses" are actually fixed resistors on the motherboard.
 
  +
  +
== Production Mode ==
  +
  +
The production mode fuse in the SoC controls not only whether JTAG/SWD is enabled on the AP or not, but also controls what UID and 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 and 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 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.

Revision as of 02:06, 4 January 2022

iDevice security and APTicket configuration settings are often determined by security fuses on the SoC.

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 that can override security configuration normally set 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 and it could have overrides enabled. 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 not only whether JTAG/SWD is enabled on the AP or not, but also controls what UID and 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 and 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 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.