Skip to content
English
  • There are no suggestions because the search field is empty.

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.

Decision table: "I want to…"
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.

Reading the filenames

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.

The full map
Folder Scripts
01-getting-started/ (3) token_id.py · bist.py · token_claim.py
02-prove-device-identity/ (6) token_auth.py · host_auth.py · host_auth_priority.py · host_auth_hrwrequest.py · mutual_auth.py · mutual_auth_host.py
03-derive-session-key/ (6) token_auth_ek.py · token_auth_ek_rsa2048.py · host_auth_ek.py · host_auth_ek_rsa2048.py · host_auth_ek_priority.py · host_auth_ek_priority_rsa2048.py
04-sign-and-verify-data/ (6) hrwrequest.py · hrwrequest_priority.py · hrwrequest_ek.py · hrwrequest_ek_priority.py · hrwrequest_ek_rsa2048.py · hrwrequest_ek_priority_rsa2048.py
05-attest-boot-chain/ (3) secureboot.py · secureboot_host.py · secureboot_hrw.py
06-chain-multiple-items/ (3) daisychain.py · daisychain_host.py · daisychain_hrw.py

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