TrustWeak device identity
Keys generated in software, shared across platforms, or verified only at the network layer. No hardware trust root means identity can be cloned or forged without physical access.
nRF52840 · ATECC608A · Thread · HPKE · MCUboot
Hardware-rooted, gateway-blind industrial IoT security
Telemetry is signed in secure hardware and encrypted on the sensor before it enters the network. The gateway verifies and forwards, but cannot decrypt. Plaintext appears only inside a controlled cloud boundary that can be deployed in European or customer-controlled environments.
Gateway-blind
Customer-controlled decryption boundary
EU-hosted or self-hosted
Hardware-rooted identity
Trust statement
End-to-end means the gateway is outside the confidentiality boundary — and decryption stays inside infrastructure you control.
The problem
Gateways that decrypt are accidental trust concentration points
Many industrial IoT platforms encrypt data in transit but terminate encryption at the gateway or edge processor. Plaintext appears at the first aggregation point — the same box that routes, buffers, and integrates data. That widens compliance scope, concentrates insider risk, and creates audit problems that no amount of TLS can resolve. For many EU and German buyers, this is not only a security problem but a sovereignty problem: the more systems that can see plaintext telemetry, the larger the operational, contractual, and jurisdictional exposure.
Early decryption
TLS terminates at the gateway. From there, telemetry is in the clear — exposed to every integration, log stream, and operator session on the edge device.
Compliance overreach
When the gateway can read customer data, it enters scope for every regulation, audit, and breach notification framework — even if it adds no analytical value.
No fleet lifecycle
Many IoT platforms stop at transport. Firmware updates, rollback safety, and device lifecycle tracking are left to manual scripts and hope.
The TrustKern approach
Hardware-rooted identity, signed envelopes, encrypted payloads, gateway-blind forwarding
ATECC608A secure element
ECDSA P-256 signing key generated and held on-chip. Private key never visible to firmware, JTAG, or any external interface.
BLE provisioning, then Thread
Devices are commissioned over BLE GATT via the iOS app. BLE is disabled after provisioning. All operational telemetry flows over Thread 802.15.4 mesh.
Signed CBOR + HPKE payload
Every message is a deterministic CBOR envelope — signed with the hardware key and encrypted with HPKE. The gateway receives ciphertext only.
Defense-in-depth verification
Signatures and anti-replay checked at the gateway, then checked again at the collector. Two independent verification points before any data is stored.
How TrustKern works
From commissioning to controlled decryption
Nine steps, three trust boundaries. The gateway sits between the device and cloud boundaries — transporting and verifying, but never decrypting.
01Key genesisATECC608A generates P-256 keypair on-chip
02BLE provisioniOS app reads identity, backend signs bundle
03BLE offbt_disable() — radio fully shut down
04Thread joinSensor attaches to 802.15.4 mesh
05Sign + encryptCBOR envelope, ECDSA sig, HPKE payload
06Gateway verifySig check, anti-replay — no decrypt
07MQTTS publishRaw ciphertext over mTLS
08Collector verifySecond sig check, dedup, anti-replay
09Decrypt + storeHPKE open, parse, persist, lifecycle
Sensor board — nRF52840 SoC + ATECC608A secure element. Signing key generated on-chip and never exportable. Payload encrypted with HPKE before leaving the device. BME688 environmental + BMI270 motion sensors.
Edge relay — Raspberry Pi with OTBR for Thread border routing + tk-gateway application. Verifies ECDSA signatures, enforces boot_id/seq anti-replay, publishes raw encrypted envelopes over MQTTS. No decryption keys, no plaintext access.
Cloud ingestion — Collector verifies signatures again (defense-in-depth), opens HPKE ciphertext, parses sensor JSON payload, persists to TimescaleDB, and updates device lifecycle state.
Trust boundary architecture
TrustKern trust boundary architecture — three boundaries, one controlled decryption point.
Why TrustKern
Not another IoT dashboard with a TLS claim
- —Identity starts in silicon. The ATECC608A generates and protects the signing key. No software key file, no export — substantially harder to extract or clone than software-held keys.
- —Gateway-blind, by architecture. The gateway holds no HPKE keys. Compromising the gateway yields ciphertext and metadata — not customer telemetry.
- —Built for battery-operated mesh. Thread 802.15.4 with sleepy end devices, not Wi-Fi-powered Linux boards. Real power budgets, real constrained links.
- —Two-stage verification. Signatures and anti-replay enforced at the gateway and again at the collector — independent checks, independent trust stores.
- —Hardware + transport + crypto + fleet ops. One architecture from secure element through OTA lifecycle — not four vendors stitched together.
- —Sovereignty starts with trust boundaries. TrustKern reduces the number of systems that can see plaintext telemetry and supports customer-controlled deployment models for regulated environments.
Sovereignty-first architecture
Designed for control over where data is visible, decrypted, and governed
In regulated European environments, the main question is often not only whether data is encrypted, but where plaintext appears, who operates the systems that can access it, and under which legal and contractual boundaries those systems run. TrustKern is designed to reduce exposure at intermediary layers and support deployment models where decryption and storage stay inside infrastructure chosen and controlled by the customer.
Minimized intermediary trust
The gateway relays and verifies, but does not become a plaintext processing point. Fewer systems with access to sensitive data means a smaller operational, contractual, and jurisdictional footprint.
Controlled decryption boundary
Plaintext appears only in a cloud-side boundary selected by the deployment model. Decryption scope can be aligned with audit, data residency, and contractual requirements.
Flexible hosting posture
Suitable for EU-hosted, customer-controlled, or self-hosted environments. The core trust model does not change when the hosting model changes.
Deployment models
Three deployment postures, one trust model — decryption always stays inside the boundary you choose.
Architecture comparison
Typical IoT cloud vs. TrustKern
Typical IoT cloud architecture
- TLS to the gateway
- Plaintext at the edge
- Gateway becomes a trust concentration point
- Sovereignty depends on intermediary systems
- Device identity often software-based
- No controlled decryption boundary
TrustKern architecture
- Encryption on the sensor
- Gateway verifies but cannot decrypt
- Plaintext only in a controlled decryption boundary
- Supports sovereignty-sensitive deployments
- Hardware-rooted identity (ATECC608A)
- Customer-controlled hosting models
Core capabilities
What the platform provides
Hardware-rooted identity
ECDSA P-256 keypair in ATECC608A slot 0. On-chip generation, non-exportable private key, PoP-based onboarding.
BLE secure provisioning
GATT service for identity read + provisioning write via iOS app. Backend-signed bundles. BLE radio disabled after commissioning.
Thread mesh telemetry
IEEE 802.15.4 low-power mesh. Sleepy end devices with configurable poll periods. Designed for battery-operated, dense deployments.
Gateway-blind encryption
HPKE (X25519 + AES-128-GCM) encrypted payload inside signed CBOR envelope. Gateway never holds decryption keys.
Signed CBOR envelopes
Deterministic CBOR wire format with version, sensor ID, boot_id, seq, timestamp, flags, ciphertext, and ECDSA signature.
Defense-in-depth
Signature verification and anti-replay at the gateway (first check) and collector (second check). Two independent enforcement points.
Anti-replay & integrity
boot_id (monotonic across reboots) + seq (monotonic within boot). Gateway and collector both enforce ordering independently.
Fleet observability
Per-sensor health tracking, gateway heartbeats, firmware version tracking, and operational metrics — without exposing plaintext at the edge.
OTA-ready architecture
MCUboot dual-slot bootloader, signed firmware, staged rollouts, health-gated confirmation, and automatic rollback.
Real telemetry, real dashboards
Live fleet and sensor observability
Production data from a TrustKern sensor fleet — decrypted and visualized only inside the controlled cloud boundary. The gateway never sees this data in plaintext.
OTA & fleet lifecycle
TrustKern is not just a transport layer
Long-lived industrial fleets need managed firmware delivery, safe rollback, and per-device lifecycle tracking — not manual reflashing over serial cables.
MCUboot dual-slot boot
A/B image slots with swap-based upgrade. New firmware boots in test mode — confirmed only after health checks pass. Automatic revert if confirmation fails.
Signed firmware delivery
ECDSA-P256 signed images. Separate production and development signing keys. Unsigned images rejected by MCUboot before execution.
Staged rollouts
Lab → production rings with per-device status tracking. Auto-pause on failure thresholds. Operator-controlled promotion between rings.
Per-device lifecycle
Backend tracks firmware version, rollout state, boot history, and health per sensor. Gateway drives MCUmgr upload over Thread. Collector updates status from OTA events.
Rollout lifecycle
Health-gated confirmation per device, staged rollout across fleet rings. Auto-pause and rollback on failure.
Where it fits
Industries and use cases
Organizations where the edge gateway must not be a decryption point — and where device provenance, auditability, and fleet lifecycle are operational requirements.
Manufacturing
Environmental and process monitoring in multi-vendor plant environments. Gateway-blind encryption keeps shop-floor telemetry out of shared edge infrastructure.
Critical infrastructure
Reduced blast radius when relay compromise does not expose bulk sensor data. Hardware-backed device identity for accountability across distributed assets.
Energy & utilities
Battery-operated mesh sensors with long deployment lifetimes. OTA-capable architecture for strict change management and verifiable software lifecycle.
Healthcare & labs
Environmental monitoring and instrument telemetry in hybrid trust environments. Minimizing plaintext at the edge supports governance models that justify every processing step.
Regulated logistics
Condition telemetry through third-party relay hubs. End-to-end ciphertext reduces reliance on intermediaries' security posture. Cryptographic device provenance for chain-of-custody.
High-assurance environments
Architectures that plan for hostile intermediaries. Payloads remain sealed until explicitly opened inside controlled decryption boundaries.
Security & governance
Architectural controls, not sticker claims
TrustKern is designed for regulated environments. Specific certifications depend on your deployment, jurisdiction, and threat model.
- Hardware-backed signing identity. ATECC608A generates and protects non-exportable keys. Tamper-resistant hardware with active shield, glitch detection, and DPA countermeasures.
- Gateway is not a trust anchor for data. Signature verification and anti-replay enforcement — but no access to payload plaintext or HPKE private keys.
- Two-stage independent verification. Gateway and collector verify signatures against separate allowlist copies. Both enforce boot_id/seq anti-replay independently.
- Controlled decryption boundary. Decryption keys remain inside the controlled cloud-side decryption boundary. Decryption scope can be aligned with audit and data residency requirements.
- Sovereignty-aligned options. European hosting, customer-controlled environments, and deployment patterns that map to contractual and regulatory boundaries.
No fabricated certification badges, customer logos, or compliance metrics on this page. Security claims are architectural. Your assurance posture is implemented with your legal and security teams.
Deployment
Deployment models for sovereignty-sensitive environments
TrustKern supports deployment models where security and jurisdictional control matter at the same time. Gateway components remain outside the payload confidentiality boundary, while cloud-side ingestion and decryption can be placed in infrastructure selected by the customer. This supports EU-hosted, customer-controlled, or self-hosted operating models without changing the core trust model.
EU-hosted
Deploy cloud components in European infrastructure with controlled operational boundaries. Edge gateway on Raspberry Pi + OTBR, cloud stack via Docker Compose — backend, collector, Mosquitto, TimescaleDB, step-ca, Grafana.
Customer-controlled
Place ingestion and decryption inside infrastructure operated or owned by the customer. The trust model stays the same — the gateway still cannot decrypt, and decryption keys remain inside your boundary.
Self-hosted
Run the platform in private environments where data governance and operator access need tighter control. All components are containerized and designed for air-gapped or restricted-network operation.
Get started
Explore a deployment model that keeps decryption inside infrastructure you control
Sovereignty-focused architecture walkthrough, EU and customer-controlled deployment options, or integration planning for regulated environments.
Book a sovereignty-focused walkthrough
Secure element identity, gateway-blind path, controlled decryption boundary, OTA lifecycle, and EU or customer-controlled deployment models.
Or reach us at info@trustkern.de
Talk to us
For partnerships, procurement, and media inquiries.
Engineering & security teams: Structured context helps — threat model, target regions, sovereignty requirements, integration constraints, fleet size.
Secure element to cloud. No plaintext at the gateway. Decryption inside your boundary.
See how TrustKern fits regulated environments with EU-hosted, customer-controlled, or self-hosted deployment.