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

Access & Credentials: Your CyberRock Access Package

Who this is for: Anyone setting up the SDK for the first time. You'll be prompted for these values during installation, so it helps to have them ready.

What you'll accomplish: Understand which credentials you need, where each one comes from, and where each one ends up.

Get this before you start. The setup scripts will prompt you for the values below. Request your CyberRock access package from your SandGrain representative ahead of time so you're not blocked mid-install.

What's in the access package

Your access package provides the cloud-side credentials the SDK and Cloud agent use to reach CyberRock:

  • CyberRock base URL

  • Device ID

  • Cloudflare Access ID and Cloudflare Access secret

You'll also need:

  • Tenant email / password: your TrustBridge login identity.

  • MQTT host / port / username / password: where the broker lives. For local testing this is your own machine; in split setups it's the machine running the TrustBridge stack.

Where each credential is written

You don't edit these files by hand, the setup scripts write them for you based on the prompts. Knowing where they land helps when troubleshooting:

Credential Written to
CyberRock base URL, Device ID, Cloudflare Access ID/secret The Cloud app's .env
MQTT host / port / user / password .env, .env.gateway, .env.device (depending on the launcher)
Tenant email / password device_credentials.json
BE_URL (default http://<MQTT_HOST>:3000/api) Used by the Gateway to sync its device whitelist from the backend

How authentication actually works

  • Hardware-backed mutual authentication happens via the SandGrain Token: a Challenge Word / Response Word exchange between Device, Gateway, and Server, plus firmware verification and installation authorization flows.
  • Each device node needs its SandGrain Token connected via USB/SPI. The Token's TID must be registered in the Gateway whitelist (auth_db_whitelist) before authentication can succeed. (Enrolling a device in the TrustBridge frontend adds its TID to that whitelist.)
  • The secret key never leaves the chip. The SDK never exposes it.

First-run TrustBridge login

When you open the TrustBridge frontend for the first time (typically http://localhost:5173), the initial username and password are both TrustAdmin. The first-run flow walks you through setup and then lands you on the dashboard.

Security recommendations

  • Ship production builds with debug flags disabled.
  • Set bit-flip thresholds explicitly and intentionally (see Compile-Time Configuration).
  • Keep secret keys inside the crypto chip, never exposed by the SDK.
  • Protect your MQTT and cloud credentials, and accept only whitelisted TIDs.