Each device in Sentinel Network is identified by a unique device_id and authenticated via ES256 (ECDSA P-256 + SHA-256) digital signatures. A device’s public key is provisioned at manufacture and registered with Sentinel before the device ships — the private key never leaves the device.

​
How It Works

1

Sentinel registers the device at manufacture

Each device’s ES256 keypair is generated and its public key is registered with Sentinel during manufacturing. Devices are sold directly to gamers and arrive pre-registered — no setup is required by the publisher or the gamer.
2

Device signs a session payload

At the start of each game session, the device constructs a small JSON payload containing a timestamp and a unique nonce, then signs it with its private key.
3

Game client forwards the payload

Your game client (using the Sentinel SDK or a direct API call) receives the signed payload from the device and passes it — unchanged — to your game server.
4

Game server calls Sentinel

Your game server forwards the payload and signature to the Sentinel /v1/device/check endpoint. Sentinel verifies the signature, checks replay protection, and returns the device’s status, reputation score, and any active bans.

​
Payload Signing

The device produces two values that your game client passes through to the game server: Your game client does not need to inspect or modify these values. Pass them as-is to your game server, which includes them in the /v1/device/check request.

​
What the payload contains

​
Check request format

​
Signature Verification

When your game server submits a check, Sentinel performs these steps in order:
  1. Base64 decoding — decodes payload_b64 and sig_b64
  2. Signature verification — verifies the signature against the device’s registered public key using ES256
  3. Payload parsing — deserializes the JSON payload
  4. Timestamp validation — ensures ts_unix_ms is within an acceptable range of server time
  5. JTI check — ensures this nonce has not been seen before (replay protection)
  6. Publisher/game match — verifies the publisher_id and game_id match the authenticated request
If any check fails, the API returns a 400 with a descriptive error code:

​
Replay Protection

Each payload includes a unique jti nonce. After successful verification, Sentinel stores it for 10 minutes. Any request reusing the same JTI within that window is rejected with replay_detected.

​
Device Revocation

Devices can be revoked from the dashboard. Once revoked, all checks for that device return "status": "revoked" instead of "ok". Bans and reputation are still returned for informational purposes.

​
Sandbox Simulator

For development and integration testing, Sentinel provides a software simulator that generates cryptographically valid DeviceCheckRequest payloads without requiring physical hardware. The simulator generates a real EC P-256 key pair and a sim_-prefixed device ID on first run, then persists them so the same identity is reused across test sessions. It signs payloads identically to real hardware, so your server-side verification code works unchanged against simulated devices. See the Client SDK — Sandbox Testing section for usage instructions.