Security Model
Status of this page. This page describes the security properties of the VCA pinpad in the current release. It applies identically to the wallet app and to the SDK. It reflects the findings of the M6 review (ORBIT-VCA-2026-001), which showed that the code and keypad displayed by the pinpad can be reconstructed from captured frames.
Scope of current deliveries. Deliveries up to and including M9 are functional demo and pilot builds. They do not implement Interstellar's targeted security, and must not be relied on to protect real funds against the adversaries listed below as not mitigated.
1. What the VCA pinpad guarantees, and what it does not
Role of the VCA layer. PoHI's security model does not rely on the VCA layer for confidentiality. Its role is integrity: it provides the foundation of an approval, a one-time challenge bound to one transaction and one device session, on which additional layers build to strengthen intent integrity, meaning that what executes is what the human deliberately authorized (section 5).
The pinpad provides single-use, transaction-bound approval: each approval challenge is generated for one transaction and is valid only within that transaction's window.
Consistent with this role, the pinpad does not protect the confidentiality of what it displays. Anything rendered for a human to perceive can be observed by a screen recorder or a camera. Dynamic visual cryptography relies on temporal integration (persistence of vision), and a recorder integrates captured frames the same way. Human readability and machine readability share one mechanism, so neither can be granted without the other.
What dynamic visual cryptography provides is narrow: a single frame shows only a random subset of segments, so one screenshot does not reveal the code. Any capture of several frames, or a camera, recovers the code and the keypad.
2. Adversarial model
| Adversary | In scope | Protection in the current release |
|---|---|---|
| Replay of a recorded approval in another session | Yes | Mitigated: challenges are single-use and bound to one transaction |
| Single screenshot of the approval screen | Yes | Mitigated: one frame does not reveal the code |
| On-device malware capturing the screen (MediaProjection, accessibility service, root) | Yes | Not mitigated |
| On-device malware or AI agent capturing the screen and injecting input | Yes | Not mitigated: it can complete the approval currently displayed |
| Overlay or clipper malware that reads the displayed code and recipient | Yes | Not mitigated |
| External camera with line of sight to the screen | Yes | Not mitigated |
MITRE ATT&CK T1410 (Screen Capture) is not mitigated by the pinpad.
3. Security properties
3.1 Single-use, transaction-bound approval
Each challenge is valid for one transaction and one window. A recorded interaction has no reuse value, so cross-session replay is prevented.
Limit. This does not protect the transaction currently being approved. An adversary that reads the live challenge can complete that approval. Device binding does not help when the adversary runs on the same device.
3.2 Single-frame illegibility
Each frame lights a random subset of each digit's segments, so a single captured frame does not reveal the code.
Limit. A per-pixel maximum or mean over a few captured frames reconstructs the code and keypad. This property offers no protection against any adversary able to capture more than one frame.
4. Residual risk
An adversary holding a screen-capture channel on the device (or a camera with line of sight), together with a way to enter input, can approve the transaction currently displayed without the user. In the current release, the pinpad adds no protection beyond single-use binding for that transaction.
5. Foundation for later layers
The VCA layer serves as the foundation of PoHI's intent integrity, not as a confidential channel. The current release establishes the building blocks that later layers extend:
- One-time, transaction-bound challenges. Every approval already belongs to exactly one transaction, which is the anchor for binding the approval to the transaction's content.
- Device-bound sessions. Each challenge is tied to the device and session it was issued for.
- Garbled-circuit rendering. The challenge is produced by a garbled-circuit renderer, which later layers extend to carry transaction-specific data.
The direction beyond M9 is to add layers on this foundation that address the adversaries listed above as not mitigated:
- Binding the challenge to the transaction content, so that a response given to a forged or altered presentation of the transaction is rejected.
- Assurance that the response comes from a human interaction, rather than from input injected by software on the device.
- Approval on a separate trusted device, or by several authorized users, for high-value or targeted scenarios.
These layers are not part of the current deliveries, and no guarantee is claimed for them. Each will be documented on this page, with its guarantees and limits, only once it has shipped and been validated, including against the reproduction in ORBIT-VCA-2026-001.