Choosing the right example: folders and filename vocabulary
Core Functions ships 27 self-contained example scripts in six folders, each named for the outcome it achieves. The integration model is simple: pick the example closest to what you need, copy it into your project, and replace the block marked YOUR INTEGRATION POINT. Nothing else is required beyond the four core modules.
| I want to… | Folder | Start with |
|---|---|---|
| Check my wiring and see the token respond | 01-getting-started/ |
token_id.py |
| Confirm the token hardware is healthy | 01-getting-started/ |
bist.py |
| Bind a new token to my tenant account | 01-getting-started/ |
token_claim.py |
| Prove a device is genuine | 02-prove-device-identity/ |
host_auth_priority.py |
| Prove the cloud is genuine too | 02-prove-device-identity/ |
mutual_auth_host.py |
| Get a session key both sides share | 03-derive-session-key/ |
host_auth_ek_priority.py |
| …and never expose it in transit | 03-derive-session-key/ |
host_auth_ek_priority_rsa2048.py |
| Tag my own data with the hardware | 04-sign-and-verify-data/ |
hrwrequest_priority.py |
| Prove which firmware actually booted | 05-attest-boot-chain/ |
secureboot_host.py |
| Cover a batch of items with one check | 06-chain-multiple-items/ |
daisychain.py |
If you only read one example: 02-prove-device-identity/host_auth_priority.py. It is the shortest complete round-trip and the pattern most integrations start from.
Folders say what you are trying to achieve; filenames follow the Core Functions scheme <flow>_<variant>.py.
Flow: who issues the challenge, and what is being proven
| Flow | Meaning |
|---|---|
token_auth |
The cloud issues the challenge (CW → RW). Verification is driven server-side. |
host_auth |
The device issues the challenge (HCW → HRW). The device decides when to prove itself. |
mutual_auth |
Both sides prove themselves; the cloud returns an HRW2 the device can reproduce. |
hrwrequest |
Ask the cloud to derive the HRW for data you supply. |
secureboot |
Attest a chain of firmware hashes. |
daisychain |
Bind several data items to one verification. |
Variant suffixes, always in this order
| Suffix | Meaning |
|---|---|
_ek |
Also derives an Ephemeral Key, a session key both sides compute but never transmit. |
_priority |
Synchronous. One call, immediate answer, no polling. Without it the flow polls for a result. |
_rsa2048 |
The EK comes back RSA-2048 wrapped, not readable in transit. Requires cryptography. |
_host |
The host/device-initiated form of a chain or mutual flow. |
_hrw |
The cloud computes what the result should be, instead of grading one you submit. |
Worked example: host_auth_ek_priority_rsa2048.py = device-initiated, derives a session key, answers immediately, key encrypted end to end.
One split to watch: the host_auth family lands in two folders. The plain, _priority, and _hrwrequest forms prove device identity (folder 02); the _ek forms derive a session key (folder 03).
Every folder has its own README with a table for choosing between variants and a sequence diagram for each script; read it before opening the code.
Before copying daisychain_host.py or secureboot_hrw.py, read Known issues and production checklist; both carry documented defects preserved deliberately.
Source code: SandGrain CyberRock - Core Functions on GitHub