Cameron Katri's Manual Page Server

Manual Page Search Parameters
cryptex-image4(7) Miscellaneous Information Manual cryptex-image4(7)

cryptex-image4 — Cryptex signing and authentication as implemented for the purposes of the Security Research Device program

Cryptexes installed on to Security Research Devices (SRDs) are personalized to the target device using the same secure boot technology which authenticates the boot chain of Apple Silicon devices. This scheme is implemented with the Image4 format, which itself is a specification implemented with ASN1.

All Apple Silicon chips possess a unique silicon identity. Software which is signed for a given device is said to be "personalized" to that silicon instance, meaning that a signature which is valid for one silicon instance is invalid for every other instance.

The identity of a given instance of Apple Silicon is derived from a combination of the following dimensions.

DIMENSION ASN1 TAG TYPE
Board Identifier BORD 32-bit unsigned integer
Chip Identifier CHIP 32-bit unsigned integer
Security Domain SDOM 32-bit unsigned integer
Unique Chip Identifier ECID 64-bit unsigned integer
Certificate Production Status CPRO Boolean
Certificate Security Mode CSEC Boolean

An authentic Image4 manifest must be obtained by querying Apple's Trusted Signing Service <http://tss.apple.com> with an identity and a list of trust object measurements to sign. If the signing service deems the collection of measurements to be permitted for installation on the silicon instance specified in the signing request, it will return a signed manifest which may then be used to authenticate the trust objects.

This manifest lists all dimensions of the silicon instance's identity and employs them as constraints on the execution environment for each trust object in the manifest. In turn, the constraints of the manifest themselves are constrained by the certificate, usually by employing distinct certificates for different chip families (as distinguished by the , , and identifiers ). This prevents one compromised certificate from being used to sign arbitrary manifests. This chain of constraints is validated in its entirety before executing the objects in a manifest. An invalidly-signed manifest cannot be recognized on any instance of silicon, and a validly-signed manifest may only be recognized as valid on a single instance of silicon.

Because a limited number of SRDs have been produced, their identities are all known to the signing service (in essence, by maintaining a list of unique chip identifiers). This permits the signing service to grant requests for these specific devices that it would otherwise decline. It is this policy primitive which authenticates cryptexes and ensures that they are not useable on non-research devices.

SRDs are physically distinguished from normal devices by a "research fuse" whose state is not alterable after manufacturing. This fuse is not currently consulted for authentication decisions, and the device boot manifest does not constrain this aspect of an SRD's identity. However, future revisions of silicon ROM may begin to recognize this fuse and boot manifest constraints on it.

While the fuse is not used to authenticate the secure boot chain of the device, it is consulted by the RESEARCH variant of the boot loader. If this variant detects that it is executing on a non-research-fused device, it will halt boot. Moreover, non- RESEARCH variants of the boot loader are not able to be flashed on to SRDs. This policy ensures that a RESEARCH boot loader is not useful on non-research devices.

The SRD also boots with a specific RESEARCH kernel image which contains the RELEASE xnu and RESEARCH variants of select kernel extensions to permit targeted expansions in the device's execution policy.

Additionally, cryptexd(8) will query the host device's research fusing status before initializing any of its other subsystems. If it detects that it is executing on a non-research-fused device, it will abort. This ensures that cryptexd(8) is not useful on a non-research-fused device.

As another layer of protection, the kernel driver which cryptexd(8) uses to mount a cryptex disk image ships a RESEARCH variant in the RESEARCH kernel image. This variant recognizes an additional entitlement to permit access to its IOKit user client that the RELEASE variant does not. cryptexd(8) possesses only this entitlement for the purpose of mounting disk images. Therefore, even if cryptexd(8) were made to execute on a RELEASE kernel image configuration, it would be powerless to perform its basic tasks.

The signing manifest required to execute a cryptex contains three objects.

OBJECT ASN1 TAG DESCRIPTION
Disk Image cpxd A disk image encapsulating a read-only, HFS+-formatted filesystem. This object's measurement is enforced by cryptexd 8 prior to mounting the disk image by reading the disk image file and computing the sha2-384 digest over it.
Loadable Trust Cache ltrs A loadable trust cache containing code directory hashes (CDHashes) of all Mach object files in the disk image's filesystem. This object's measurement is enforced by the kernel monitor which is responsible for code signing decisions. Once executed, the CDHashes in this trust cache are permitted to execute as equivalent to platform code.
Info.plist c411 A plist 5 which contains identifying information about the cryptex, namely a CFBundleIdentifier and a CFBundleVersion . This object's measurement is enforced by cryptexd 8 . Once executed, the bundle identifier in this plist 5 is reserved for this specific cryptex, and no other cryptexes may be installed with this identifier.

The object is recognized by cryptexd(8). Therefore, any other subsystems which authenticate disk images in order to mount them cannot recognize authentication information in a cryptex manifest. This is an additional layer of protection which ensures that a valid cryptex manifest is not useful on non-research-fused devices.

Image4 manifests which execute on the Application Processor of an Apple Silicon SoC are signed with a nonce ("Number used only ONCE") whose representation is obscured by way of entanglement with a private key that is unique to the silicon instance. Because the device's participation is required to generate a new manifest nonce, an attacker cannot produce a valid manifest for the device knowing only its silicon instance identity -- possession of the device is also required.

The nonce represents a constraint in the manifest, and during validation, it is compared against the value of the current obscured nonce. A mismatch results in a validation failure even if all identity constraints are met.

Cryptex manifests are signed with a nonce whose raw value is re-generated after a software update is installed. But otherwise, the nonce value is stable across reboots, which permits existing cryptex personalizations to remain valid across that boundary.

The cryptex nonce is not currently rolled after a software update is applied.

cryptexctl(1) cryptexd(8) cryptex(5) plist(5) shasum(1)

4 September, 2020 Darwin