Skip to main content
AlphaPoint Signing Display

Read the exact request on a device nothing else can reach. Then hold to approve.

A signing device with a secure display, for the person who approves. It shows a pending action drawn from the signed record itself, not from a web page; the approver holds to approve or decline; and the device is designed to sign only the hash of exactly what it showed. What it cannot show, it does not offer to approve.

See how it worksRequest a 30-minute Security Briefing

The device shown is a design, not a shipped unit. Everything on this page is marked as built on the bench prototype or as design.

Why a separate display

Every approval passes through software you don't control.

The browser, the app, the operating system, the workstation: any of it can show one thing and send another, and the person approving never knows. A hardware key helps, but a key that signs a hash it cannot explain is still signing blind. The Signing Display puts the reading, the decision and the approval on a device the network and the workstation cannot reach.

What it shows

The request, from the record

Kind and risk up front; the amount, large; the full destination, never a hash; every warning; the signed statements of who vouches; how many approvals the policy needs. A field the display cannot show faithfully refuses the whole request rather than guess.

The decision

A hold, not a tap

Approve and Decline are both holds of a second or more, the length a setting. The ring that runs round the edge of the glass is the display's own clock, not the sender's. A tap, a swipe or a message from the network cannot produce an approval.

The one rule

No signature without a hold over the hash that was shown

The device signs a hash only if it equals the hash of the record it has just displayed and the hold completed; one confirmation, one signature. The rule is a small program checked with a model checker as part of the firmware's own tests.

Rule proved

The design

Two chips, three roles. No host, no USB, no browser.

The device dials out over Ethernet to its home on the platform; it never listens. It has its own power supply, no port for a computer and nothing to install.

One chip carries two cores, the network core and the secure core, kept apart by the chip's own bus fences; the other chip is the trusted display processor. Part names are deliberately absent; they belong to the engineering record, not to a product page.

The network core, which sees only ciphertextOne core of the first chip. Carries the session's packets and decides nothing. It is fenced from the keys by the hardware, not by its code.
The secure core, which holds the keysThe other core of the first chip, in its own hardware domain. Ends the authenticated session, checks every message, keeps the device's keys inside a secure element, applies the one rule, and drives both chips' updates.
The trusted display processor, which owns the panel and the touchThe second chip. Draws the fields it is sent in its own fonts, measures the hold, and answers “confirmed” over the hash it showed, on a link authenticated with a pairing key set at the factory.
Updates: one bundle, both or neitherSigned images, two slots on each chip, a paired trial that must prove itself before it is kept; any failure rolls both back. Secure boot, encrypted storage and anti-rollback on both chips in a shipped unit.
Where it stands

Built on the bench, and design.

  • ✓
    The display and the touchThe trusted display processor drives the 8-inch panel and reads its touch on the bench prototype.
  • ✓
    The approval screenDrawn from the request's fields by the device's own renderer: amounts, addresses in full, warnings, signed statements, the quorum line, paging, the hold and Decline.
  • ✓
    The refusalA request with a character no font can draw is unshowable: no approval is offered.
  • ✓
    The one rule and the link framesWritten as a small library with host tests and model-checker proofs; the frames between the two chips authenticated and replay-refusing in the library.
  • ○
    The hardware fence between the two coresSpecified; to be proved on the development board.
  • ○
    Ethernet, the session and the device keysThe network core, the authenticated session to the platform and the keys in the secure element.
  • ○
    Signed updates and the paired trialSecure boot, the bundle, the trial and rollback on both processors.
  • ○
    The platform's sideVerifying the device's signature as an approval grade, enrolment by safety numbers, the console.
  • ○
    The device itselfIts own board, its case, a tamper switch, and the product's name clearance.

The bench prototype is a development board set; it is not the shipped form. Nothing on this page states when, whether or at what price the device ships.

Try the walk-through

See one approval end to end.

An eight-step illustrative walk-through: the problem, where the keys live, what your people see, a request you read and hold to approve or decline yourself, and what follows. Inert: nothing is sent or signed.

See how it worksTalk with the teamRequest a 30-minute Security Briefing

Preview of a design in development · Not a shipped product · No availability, date or price · The screens are illustrative and the amounts are placeholders · No customer deployment is represented.