ArdaPackage integrity
Ed25519 signature over the bundle, verified before decryption. Fail the check and the previous release keeps running — a bad package can't take a device down.
Hardware you don't own,
running code you do.
An ArdaForm device sits on a counter, in a warehouse or in a reception area. Strangers can touch it, unplug it, open it and walk off with the disk. Everything below starts from that assumption rather than pretending otherwise.
01 / Threat modelWhat we
What we
defend against.
Being specific about this is more useful than a page of adjectives. Here is what the design takes seriously, and what it doesn't claim to solve.
| Scenario | Mitigation |
|---|---|
| Someone copies the disk to read your source | The application ships as an encrypted .arda bundle, not a readable directory. The decryption key is derived on the device rather than stored beside the package. |
| Someone copies your package onto their own hardware | A package can be bound to a device, an installation, a customer or an account. A bound package refuses to load anywhere else. |
| Someone substitutes a modified application | Every package carries an Ed25519 signature verified before it is unpacked. The signing key never leaves your build machine — the control plane cannot sign on your behalf. |
| Someone tampers with an update in transit | Updates are fetched over HTTPS and checked against a SHA-256 named on the control channel. Runtime binaries additionally require a valid Ed25519 signature from the release key. |
| Someone scans the customer's network for your device | Devices open no inbound ports. All communication is a single authenticated outbound connection the device initiates. |
| A dependency in your bundle tries to phone home | The page has no network stack. There is no fetch to an arbitrary host — data moves only through the sync bridge to your own server. |
| The device is stolen with a day of transactions on it | Local databases and the outbound queue are encrypted at rest with hardware-derived keys. Pulling the disk yields ciphertext. |
| A support session is abused | Console, evaluation and shell access are operator-initiated, individually authorised, short-lived and logged. There is no standing back door. |
| A biometric image leaks to a cloud provider | Face detection and matching are designed to run entirely on the device. No image is uploaded for recognition. |
!
What we won't claim
No software makes a device that a determined attacker physically owns "secure". Given the hardware, unlimited time and enough skill, defences on that hardware can be worn down. What ArdaForm provides is depth — several independent things must fail before your code or your customer's data is exposed — and a cost of attack far above casually copying a folder of JavaScript.
02 / LayersSix independent
Six independent
controls.
Each one is useful alone. The point is that an attacker has to beat several of them in sequence.
Package confidentiality
AES-GCM encryption of the application payload, decrypted into memory at load. Your business logic isn't sitting on the filesystem in plain text.
Device identity
A stable ID derived from the machine, not a value the device is told to use. It survives reboots and changes only when the hardware or OS install does.
Capability scoping
The manifest declares what the application may reach. Everything else is absent from the injected namespace — not merely refused at call time.
Outbound-only transport
One authenticated connection, initiated by the device, over TLS. No listening socket for anything on the customer's LAN to find.
Data at rest
Local stores and the durable outbound queue are encrypted with hardware-derived keys, so a removed disk is not a data breach.
03 / Keys
The server never
The server never
holds your key.
Two independent Ed25519 keys are involved, and the control plane holds the private half of neither. That's deliberate: a compromise of the ArdaForm platform must not be enough to sign code that runs on your customers' hardware.
| Key | Signs | Private half held by |
|---|---|---|
| Pack key | Your .arda application packages | Your build machine or CI runner |
| Release key | ArdaPlayer runtime binaries | The ArdaPlayer release pipeline |
i
Your responsibility
Keep the pack key out of your repository and in your CI secret store. If it leaks, rotate it and re-sign — the platform can revoke a key from the fleet, but it cannot un-sign a package that was already made with it.
verification order on the device
// 1 — transport
TLS to the control plane ✓
Server certificate pinned ✓
// 2 — artefact
SHA-256 matches the instruction ✓
Ed25519 signature valid ✓
// 3 — binding
Package bound to this device? ✓
Installation still registered? ✓
// 4 — payload
AES-GCM tag verifies ✓
Manifest parses, caps resolved ✓
// any failure → discard, keep running the
// previous release, report the error upstream04 / OperationsAccess that
Access that
leaves a trace.
Remote console, live evaluation and shell access are genuinely powerful. Powerful things need boundaries around them.
Operator-initiated
A session starts because a person asked for it, against a named device, from an authenticated account.
Short-lived tokens
Tunnel access is granted by a single-use token with a short TTL, bound to one device.
Auditable
Who connected, to which device, when, and for how long — recorded rather than reconstructed.
Revocable
Account tokens are scoped per fleet and can be revoked without touching a single device.
@
Reporting a vulnerability
If you believe you have found a security issue in ArdaForm or ArdaPlayer, use the contact form with Security report as the topic, and enough detail to reproduce it. Please give us a reasonable window to fix it before publishing. We will confirm receipt, keep you updated, and credit you if you'd like us to.
What people
are building.
Tills, kiosks, signage, attendance terminals, industrial panels and Raspberry Pi products — the shapes ArdaForm was designed around.