Skip to main content
For the complete documentation index, see llms.txt.

Hubble Network developer documentation: integrate Bluetooth devices with terrestrial and satellite connectivity.

Device Encryption Modes

Hubble Network supports multiple device encryption schemes compatible with your hardware, with configurations to ensure transmission privacy.

Overview​

Your device is anonymous end-to-end on Hubble Network because the Device SDK encrypts and rotates IDs. Device ownership is only determined on our backend after transmissions are received, so that we can securely deliver the data packet to your organization.

Configurations​

The Hubble Device SDK handles all this based on your selected encryption mode, which is a function of the encryption algorithm, key size, and counter source – and for IN100, a custom configuration called the period exponent.

Encryption Algorithm​

When you register devices to your Hubble organization, you must specify encryption mode for Ephemeral ID (EID) rotation. Hubble Network supports two primary device encryption schemes that govern EID rotation, based on your hardware capabilities:

  • AES-256 / AES-128 (Standard): Uses AES-CTR (counter mode) and CMAC. Set key size and counter source. Best for standard BLE devices.
  • AES-128-EAX: An Authenticated Encryption (AEAD) mode specifically optimized for IN100 (nanobeacon) chips. Must use device uptime as counter source. Set period exponent to define EID rotation period (the rotation period is calculated as 2^n seconds, where n is the period_exponent).

Key Size​

Hubble Network supports AES-256 and AES-128 length keys. 256-bit is recommended.

Counter Source​

Use unix time to rotate EIDs if your hardware can maintain an accurate, synchronized clock. Otherwise use device uptime, which does not require the device to know current time. AES-128-EAX encryption mode requires "DEVICE_UPTIME" counter source.

Comparing Encryption Modes by Counter Source​

FeatureUNIX_TIME (Default)DEVICE_UPTIME
Supported algorithms /
Key sizes		AES-256, AES-128AES-256, AES-128, or AES-128-EAX (required for IN100)
Best forDevices with reliable time sync; maximum privacy.Devices without a time source; best for "out-of-the-box" provisioning (e.g. IN100).
Time syncRequired. Device must maintain current Unix epoch time across power cycles.Not Required. Ideal for simple hardware without a time-aware Real-Time Clock (RTC).
Reset behaviorPersistent. EIDs remain unique as long as the UTC clock is maintained.Volatile. Counter typically resets to 0 (or a number in the pool) on boot.
Rotation logicTime-Based. EIDs are derived from the current UTC epoch and never repeat.Pool-Based. Increments by device uptime counter within a fixed pool; wraps at the pool_size constant.
Clock drift+/-1 epoch in counter value is permissible.Does not apply.
EID validityStrict. Advertisement packets must be rotated at least every 24 hours to generate the next valid EID.Flexible. EIDs are pre-computed on the backend; advertisements remain valid even if a rotation cycle is missed.
EID reuseNever. Unix time is the most secure encryption mode.Cyclical. EIDs repeat after pool_size rotations (default 128).

Go further: Review Onboard Devices for guidance on how to register a new device to your Hubble organization with your specified security configuration.