Validation, Test Procedures & Certification

Who this is for: QA engineers and integrators validating a SandGrain setup before sign-off.

What you'll learn: What to validate, the eight PoC menu options and their expected outcomes, and the checklist to confirm production readiness.

What to validate

Functional: run PoC Option 1 and confirm Mutual Authentication OK / AUT_OK.
Integration: bring up the full stack and confirm five containers via docker ps, the frontend login at :5173, and Swagger at :3000/docs. Confirm the MQTT round-trip in the backend logs (Connected to MQTT broker, Subscribed to device presence).
Security: verify that unregistered devices are rejected with SGR_SDK_NOT_REGISTERED, that tampered firmware reports FW_NOK and is denied installation, and that CRC mismatches return SGR_SDK_CRC_ERROR.
Performance: exercise concurrent multi-device authentication at the Gateway (up to MAX_DEVICES), and validate behaviour under injected bit faults (Options 2 and 3).

The PoC device menu (test scenarios)

Option	Name	What it does	Expected outcome
0	BIST (Built-In Self-Test)	Sends the BIST command directly to the crypto chip (no gateway or cloud). Prints the chip's PCC, ID (the TID you enroll), RW, EK, and a status byte where `0x50` means pass.	Chip confirmed alive; TID read off for enrollment
1	Mutual Authentication (no fault injection)	The full clean auth flow through the gateway to the cloud. Phase 1 proves the device is genuine; Phase 2 proves the cloud is genuine.	`Mutual Authentication OK (Phase 1 + Phase 2)`
2	Fault injection	Same flow, but the device corrupts bits before sending (2 in the CW, 1 in the CW echo, 1 in the RW). Exercises Error Management. Phase 2 is skipped.	`AUT_OK` after Error Management resolves
3	Fault injection: Error Management stress	Heavier corruption (3 bits in CW, 2 in the CW echo). Phase 1 only.	`AUT_OK` after more candidates are tested
4	FW Verification: correct RW	Hashes a built-in test firmware blob (SHA-256), asks the chip for the matching RW, runs `SGR_SDK_Verification_FW`. Saves `RW_verify` for option 6.	`FW_OK`, permission GRANTED
5	FW Verification: wrong RW	Same flow with an all-zero RW (simulating a tampered image).	`FW_NOK`, permission DENIED
6	Installation	Requests installation authorization (`SGR_SDK_Installation`). Needs the `RW_verify` from option 4.	Authorized only after a successful verification
8	Exit	Stops the MQTT listener, cleans up, and quits.	,

Two notes. Options 1 to 3 can also be triggered remotely: the device subscribes to sandgrain/v1/<TID>/cmd/run_auth, so the frontend can fire a run with {"mode":1|2|3} without touching the menu. And in everyday demo use you really only need 0 (read the TID once for enrollment) and 1 (the actual mutual auth); 2/3 demonstrate error resilience, and 4/5/6 the firmware-update story.

Failure conditions

A difference above CW_BITFLIP_THRESHOLD fails immediately.
All candidates exhausted fails authentication.
Installation without a prior successful verification is denied (FW_INSTALL_NOT_ALLOWED).

Certification checklist

Mandatory: all device TIDs in the Gateway whitelist; the Gateway started and fully initialized before any device; correct serial/COM ports; SDK_MODE set per executable.

Recommended: CRC enabled for non-local builds; debug flags disabled; retry limits and thresholds set intentionally.

Production readiness: stack healthy (tb-mysql healthy, five containers up); end-to-end authentication observed in the frontend; firmware verification and installation gating confirmed.