Security architecture

• Confidentiality

  Telemetry and credentials are not readable in transit or at rest without authorization.

• Integrity

  Firmware, configuration, and measurements are protected against undetected tampering.

• Authenticity

  Every device and service proves identity before trust is granted.

• Availability

  Resilience to outage, replay, and flooding, with graceful degradation where possible.

• Accountability

  Audit trail for access, provisioning, OTA, and admin actions.

• Privacy

  GDPR-oriented handling of personal and site data in the cloud layer.

1. 01

   Zone Z1 - L1 field sensors

   Field nodes (CN-CC, CN-WD, and related SKUs). LoRaWAN MAC with AES-128, secure element for keys, NFC for install. No IP stack on the node.

2. 02

   Zone Z2 - Floor (CN-FG)

   Floor gateway verifies frames, stays on the local VLAN, and has no cloud-facing interface.

3. 03

   Zone Z3 - Power (CN-UPS)

   Energizes floor and building edge gear. No data conduit.

4. 04

   Zone Z4 - Building DMZ (CN-BC)

   Building controller: WireGuard client, MQTT client, OTA orchestrator. Outbound cellular path only for tunnel and broker traffic.

5. 05

   Zone Z5 - CurNext Cloud (L5)

   Application, managed database and auth, private MQTT broker, AI, and object storage behind edge protection.

• L1-L2

  No WireGuard

• L3

  No WireGuard

• L4 CN-BC

  WireGuard client - building security boundary

• L5 Cloud

  WireGuard hub - MQTT on the private mesh only

• L1

  L1 - Field sensors

  Unique device identity, LoRaWAN air-link crypto, secure boot, signed OTA, tamper-proof design, and displacement detection.

  • - Unique root key per probe in a secure element - never shared across the fleet
  • - Labels may show public serial / DevEUI for logistics - never the root key
  • - LoRaWAN Class A (EU868): AES-128 payload encryption and MIC via the MAC stack
  • - OTAA join only; frame counters and replay rejection at the floor gateway
  • - Secure boot, signed firmware, anti-rollback, production debug locked
  • - Tamper-proof field enclosure and sensing path - physical interference is detectable and reported
  • - Displacement detection when a node is moved from its assigned install position
  • - Field assign via NFC cryptographic binding - QR assign disabled by default

• L2

  L2 - CN-FG floor gateway

  Trust anchor for the air link. Validates join, MIC, and counters before forwarding.

  • - Signed firmware with secure boot and secure-element identity
  • - No default internet route; uplink only toward CN-BC on the floor VLAN
  • - OTA only from CN-BC
  • - Join and verification events retained for audit upload
  • - Service ports constrained in production images

• L3

  L3 - CN-UPS power

  Power path only - no data plane on the management VLAN.

  • - No IPs or management API on the data VLAN
  • - Locked enclosure practices at install
  • - Fault indication stays local - no network leak from power faults

• L4

  L4 - CN-BC building controller

  Building security boundary between floor LAN and cloud.

  • - WireGuard outbound from the building (CGNAT-safe)
  • - MQTT over TLS 1.3 with per-building client certificates
  • - Host firewall default deny; no public SSH, MQTT, or API on cellular
  • - Only OTA path to L1/L2: verify signed manifest and image, staged rollout, report result
  • - Store-and-forward telemetry buffer encrypted at rest; purge after successful delivery

• L5

  L5 - CurNext Cloud

  Multi-tenant application and data with private field ingress.

  • - MQTT broker reachable only on the private mesh - not on the public internet
  • - Per-building authorization; deny cross-tenant wildcards
  • - User auth with short-lived tokens; MFA required for privileged roles
  • - RBAC enforced on API routes; rate limits and edge WAF in production
  • - Encryption in transit and at rest; tenant isolation on queries
  • - Encrypted backups with restore drills; GDPR audit, export, and erasure paths
  • - Secrets kept in a secrets manager - not in source control

1. 01Offline root CA
2. 02OTA signing CA
3. 03Signed L1, CN-FG, and CN-BC images / manifests

• - Firmware signatures with ECDSA P-256 (or stronger RSA where required)
• - Manifest includes device class, version, minimum version, hash, signature, and revocation epoch
• - Compromised signing material rotated on an emergency path
• - A/B partitions on field devices with rollback on failed boot
• - Staged rollout before fleet-wide apply
• - SBOM per firmware and cloud release; continuous vulnerability monitoring
• - Critical security updates targeted within 14 days; high within 30 days

Not used: TLS 1.0/1.1, MD5, SHA-1 for signatures, or static air-link session keys without OTAA.