Security

Threat model, Secure Enclave properties, and what an attacker can and cannot do with RemoteSignerPhone.

Design principles

RemoteSignerPhone is built around three properties that together define the security posture:

Private keys live only in the Secure Enclave. Generated there, used there, never read out by the application or the operating system. There is no API path that returns key material in software.
Every signature requires user presence. Each sign operation re-prompts for Face ID or Touch ID. There is no "trust this device" or "auto-approve for an hour" mode.
Transport is encrypted point-to-point and never crosses the internet. Multipeer Connectivity sessions are encrypted, local-only, and short-lived.

The remainder of this page walks through what those mean in practice and what they cost an attacker.

The Secure Enclave is a separate processor on the same Apple silicon die as the application processor, with its own boot chain, its own memory, and its own crypto coprocessor. When RemoteSignerPhone provisions a new identity:

The Secure Enclave generates an ECDSA P-256 keypair internally.
The private key is stored in Secure Enclave-protected memory, encrypted under a key derived from the device passcode and the unique device identifier (UID) burned into the chip at the factory.
Access to the key is gated by:
- kSecAttrAccessibleWhenUnlockedThisDeviceOnly — the key cannot be used while the device is locked, and is excluded from backups (encrypted or otherwise).
- userPresence — every signing operation requires biometrics or device passcode.
- privateKeyUsage — the key can be used for signing but the bytes cannot be returned to the application.
An opaque, persistable reference to the key is stored in the iOS Keychain. The reference is what the application holds; signing requires asking the Secure Enclave to use that reference.

Apple's CryptoKit framework explicitly does not expose any function that returns the raw private key bytes. The closest is dataRepresentation, which returns an encrypted blob that can only be re-imported on the same device that produced it — and even then, only after re-authenticating to the Secure Enclave.

Practical implication: even if an attacker had full root on your iPhone, they could not extract the private key. They could potentially trigger signing operations (subject to your biometric approval), but they could not export the key for offline use elsewhere.

Biometric per-sign approval

Every signature requires Face ID or Touch ID at the moment of signing. The biometric flow is enforced by the Secure Enclave hardware, not by application code, which means RemoteSignerPhone cannot bypass it even if it wanted to. iOS's Local Authentication framework hands the biometric verdict directly to the Secure Enclave, which then either produces the signature or refuses.

This is the property that makes the rest of the architecture meaningful. A compromised Mac with vmuxAgent installed cannot silently use your keys: every signature triggers a visible sheet and a Face ID prompt on your phone. You see what host is being authenticated to before you approve.

Failure modes for the biometric layer:

Failed biometrics fall back to passcode. After several failed Face ID attempts, iOS presents the device passcode as a fallback. This is normal Apple behavior. The Secure Enclave will sign once the passcode is correct.
Biometric data is never sent off the iPhone. Face ID templates and Touch ID fingerprints stay in the Secure Enclave. They never appear in app memory, in network traffic, or in backups.
Disabling the device passcode invalidates Secure Enclave keys. If you turn off your iPhone's passcode in Settings, iOS purges all Secure Enclave-protected keys. RemoteSignerPhone identities would survive in metadata but become unusable. You'd need to provision new ones.

Transport security

The Multipeer Connectivity session between the iPhone and any paired device (Mac with vmuxAgent, Vision Pro with vmux) is configured with encryptionPreference: .required. Apple's framework establishes the symmetric session keys using device-pair-specific material; the on-wire bytes are encrypted before they leave the Wi-Fi or Bluetooth radio.

What is not on the wire:

Private keys (they never leave the Secure Enclave, period).
Plaintext sign-request data (the request payload is encrypted within the Multipeer envelope).
APNs push contents (silent pushes carry content-available: 1 only — no payload).

What is on the wire (encrypted):

The list of public keys (and labels) when a paired device asks for available identities.
Sign-request payloads — a small SSH challenge blob, the public-key identifier, and metadata like the source device name and destination host.
Sign responses — the signature bytes returned from the Secure Enclave.

A network-level attacker on your Wi-Fi sees encrypted Multipeer traffic. They cannot decrypt it, cannot see what host is being signed for, and cannot exfiltrate keys.

Threat model

What follows is a deliberate, falsifiable threat model. Each row claims a thing an attacker either can or cannot do, and why.

Attacker capability	Can they?	Why or why not
Steal the private key from the iPhone over the network	No	Private key never leaves Secure Enclave; no API exposes it
Steal the private key from a Mac with vmuxAgent	No	Mac never receives private key; only signature responses
Steal the private key from a Vision Pro running vmux	No	Same — headset only sees signed challenges
Decrypt Multipeer traffic by sniffing Wi-Fi	No	Required encryption; session keys not derived from anything sniffable
Replay a captured signature on a different host	No	SSH challenges include host-specific nonces; signature is bound to one handshake
Forge a signature without the iPhone	No	Only the iPhone's Secure Enclave can produce signatures matching the public key
Trigger a signature by pairing with the iPhone	Partial	They can pair and request a signature, but every request prompts biometrics — you see and refuse
Use the iPhone after physically stealing it (locked)	No	Keys gated on device unlock and biometrics; not extractable from a powered-on locked phone
Use the iPhone after physically stealing it (unlocked, Face ID off)	Yes for as long as Face ID is bypassed	Realistic threat — same as any unlocked iPhone; rotate keys via the app or kill identities remotely
Compromise the Mac to silently sign as you	No	Each request prompts Face ID on your iPhone; silent abuse is impossible
Restore an iCloud backup onto a new iPhone and inherit your keys	No	Secure Enclave keys are device-bound; iCloud restore invalidates them, you re-enroll on new hardware
Coerce you to approve a sign request you don't want	Yes	Out of scope for any cryptographic system; you control the biometric prompt

The "compromise the Mac to silently sign as you" row is the central security claim of the design. Putting the key on the iPhone and gating signing on biometrics makes the SSH key resilient to Mac compromise in a way that any private-key file on disk is not.

What you should still do

Set a strong device passcode. Six digits minimum; ideally an alphanumeric. The passcode is the fallback when biometrics fail, and is part of the Secure Enclave key derivation.
Enable Find My iPhone. If the device is lost or stolen, you can remote-wipe it. Once wiped, all Secure Enclave keys are gone — they can't be recovered, but they also can't be misused.
Review your servers' authorized_keys periodically. Remove old public keys whose corresponding iPhone identity you've deleted. A stale entry is harmless but invites confusion.
Disable identities you're not actively using. A disabled identity won't sign, even if a paired device requests it. This is a soft revoke that's faster than removing keys from servers.
Cross-check the destination on every Approve. The Destination field on the Sign Request sheet is your last line of defense before producing a signature. Read it before you approve.
Keep iOS up to date. Apple patches Secure Enclave vulnerabilities silently and often; a current iOS is always more secure than an out-of-date one.

Audit trail

RemoteSignerPhone itself does not retain a long-lived audit log of approvals or denials. The Status banner shows the last action and clears after a few seconds. For audit purposes, look elsewhere:

vmuxAgent on the Mac logs every request it forwarded to the iPhone, with timestamps, source process, destination host, and the iPhone's response. See vmuxAgent troubleshooting for log paths.
Server-side /var/log/auth.log (Linux) records every successful SSH authentication, including the public-key fingerprint that satisfied the challenge. Cross-reference against the fingerprints in RemoteSignerPhone identity detail screens to attribute logins to specific iPhone-held keys.
APNs delivery logs are managed by Apple and not user-visible. They contain only timestamps and device tokens.

SSH signing with iPhone — the security narrative from the visionOS side.
vmux-wide security — App Lock, Secure Enclave keys on other devices, encrypted backups.
Approving signing — the per-request approval UX.