You mostly cannot, and it is worth being precise about why, because it changes what you should actually do.
Entropy is not a property you can measure from the output. Statistical tests (dieharder, NIST STS) detect gross failure — a stuck bit, a 32-bit seed, a repeated value — but they cannot distinguish true randomness from a backdoor. A seed generated as AES(counter, attacker_key) passes every statistical test ever written and is perfectly predictable to whoever holds that key. So "the output looks random" is close to zero evidence.
What you can actually verify is the DERIVATION, and that is where dice come in.
On a Coldcard (and Passport, and SeedSigner) you can supply the entropy yourself as dice rolls. The device takes the string of roll digits, SHA256s it, and uses that 256-bit digest as BIP39 entropy. Every step there is deterministic and public, so you can recompute it independently: take your dice string, sha256 it, convert to a BIP39 mnemonic with an offline tool on an airgapped machine, and compare against what the device showed you. If they match, the device used your entropy and nothing else. That is a real verification with a pass/fail answer, unlike staring at the words.
Two caveats people miss:
Use enough rolls. A d6 gives log2(6) ≈ 2.58 bits, so 256 bits needs ~99 rolls. Fifty rolls is 129 bits — still far beyond brute force, but it is not the 256 you think you have.
Verifying the seed does not mean the device is honest afterwards. A malicious signer can leak your key gradually through biased signature nonces, which no seed check would catch. The defence there is separate: deterministic nonces plus an anti-exfiltration protocol (AntiKlepto / anti-covert-channel), where the host contributes randomness to the nonce and verifies the signature used it.
So the practical answer: supply dice entropy, recompute the derivation offline, run reproducible-build firmware so the binary matches audited source, and treat the device as untrusted for signing regardless.
