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:
ValueDescription
payload_b64Base64-encoded JSON payload (timestamp + nonce)
sig_b64Base64-encoded ES256 signature over the payload bytes
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

{
  "ts_unix_ms": 1736240400123,
  "jti": "550e8400-e29b-41d4-a716-446655440000",
  "device_fw": "1.2.3",
  "telemetry": {}
}
FieldTypeDescription
ts_unix_msintegerUnix timestamp in milliseconds — must be within an acceptable window of server time.
jtistringUnique UUID for this check, used for replay protection.
device_fwstringDevice firmware version (informational).
telemetryobjectOptional telemetry data.

​
Check request format

{
  "device_id": "dvc_abc123",
  "publisher_id": "pub_acme",
  "game_id": "game_fps_01",
  "alg": "ES256",
  "payload_b64": "<base64-encoded-payload>",
  "sig_b64": "<base64-encoded-signature>"
}

​
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:
Error CodeDescription
bad_base64Invalid base64 encoding
bad_signatureSignature verification failed
bad_payload_jsonPayload is not valid JSON
timestamp_out_of_rangeTimestamp too far from server time
missing_jtiNo JTI in payload
replay_detectedJTI already used
publisher_game_mismatchBody IDs don’t match headers
device_public_key_missingNo public key registered for this device

​
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.