Skip to content

Security, Cryptography & Authentication

The Aslandi Edge Converter incorporates hardware and cryptographic safeguards designed for mission-critical industrial infrastructure. It implements defense-in-depth principles across physical provisioning, local commissioning, offline persistence, and cloud communications.


1. Cryptographic Architecture Overview

flowchart TD
    subgraph RootOfTrust["Hardware Root of Trust"]
        OTP["RP2350 OTP / Secure Key Store
• Device Unique ID
• AES-256 Master Key
• ECDSA P-256 Root Verification Key
• Client Certificate & Private Key"] end subgraph AtRest["Security at Rest"] SDCrypto["MicroSD Blocks:
AES-256-GCM Authenticated Encryption
(12-byte IV + 16-byte GMAC Tag)"] FlashConfig["Flash Configurations:
Redundant Slots with HMAC-SHA256 & CRC32"] end subgraph InTransit["Security in Transit"] mTLS["Mutual TLS (mTLS v1.3):
X.509 Device Certificate + Private Key
Server CA Verification"] HTTPPolicy["Local Web Panel:
Isolated Subnet / SoftAP Only
Digest Auth & Strict Network Policy"] end subgraph FirmwareSecurity["Firmware Integrity"] Bootloader["A/B Verified Bootloader:
ECDSA P-256 Signature Verification
Anti-rollback Counters"] end OTP --> SDCrypto OTP --> FlashConfig OTP --> mTLS OTP --> Bootloader

2. Storage Cryptography: AES-256-GCM

Data written to the microSD card contains sensitive facility power generation and consumption profiles. To guarantee confidentiality and tamper-evidence:

  • Cipher: AES-256-GCM (Galois/Counter Mode).
  • Key Derivation: Sourced directly from hardware OTP during manufacturing provisioning; never stored in plaintext code or flash filesystems.
  • Nonce/IV: 12-byte cryptographically unique initialization vector per physical sector, derived from the sector address and block sequence number.
  • Authentication Tag: 16-byte GMAC tag appended to each block. Any bit-flip, sector tampering, or unauthorized card insertion results in immediate tag validation failure and quarantine.

3. Mutual TLS (mTLS) Cloud Authentication

All communications between the converter and the Planovi Cloud use Mutual TLS (mTLS):

  1. Client Identity: Each converter is provisioned at the factory with an individual X.509 certificate signed by the Planovi Edge Intermediate CA.
  2. Private Key Protection: The private key is injected during provisioning and cannot be extracted via the local HTTP panel or Modbus interfaces.
  3. Server Validation: The converter validates the server certificate chain against the bundled Planovi Root CA certificate.
  4. Transport: Runs over TCP port 8883 (MQTT with TLS), enforcing strict cipher suites (TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256).

4. Bootloader Verification & Dual-Slot A/B Rollback

Firmware upgrades are strictly controlled through an ECDSA P-256 authenticated bootloader:

sequenceDiagram
    autonumber
    actor Tech as Certified Service Technician
    participant USB as USB Service Interface
    participant BL as Verified Bootloader
    participant SlotA as "Slot A (Active)"
    participant SlotB as "Slot B (Candidate)"

    Tech->>USB: Mounts signed firmware candidate package
    USB->>SlotB: Writes candidate image to passive slot
    Tech->>BL: Triggers trial boot command
    BL->>SlotB: Reads ECDSA P-256 Signature Header
    BL->>BL: Verifies signature against embedded Public Key

    alt Invalid Signature or Corrupt Hash
        BL->>Tech: Rejects image and halts trial boot
        BL->>SlotA: Boots verified Slot A (Active)
    else Valid Signature
        BL->>SlotB: Boots trial image in Slot B
        SlotB->>SlotB: Executes self-test (RS-485, LittleFS, RTC, Wi-Fi)
    end

    alt Self-Test Passes (Within 300 seconds)
        SlotB->>BL: Confirms health flag (Marks Slot B as Active)
    else Watchdog Timeout or Diagnostic Fault
        BL->>SlotA: Automatic rollback to Slot A
    end
  • Remote OTA Policy (v1): In accordance with the release specifications, Over-The-Air (OTA) firmware delivery over the internet is disabled in production v1. All firmware updates must be executed by certified personnel via the physical USB maintenance interface.

5. Local Panel Network Policy

The embedded HTTP server running on the converter provides commissioning and diagnostics:

  • Prohibition of Internet Exposure: The local panel is strictly prohibited from being exposed directly to public WAN interfaces or routed corporate networks. It is designed solely for local access via the converter’s SoftAP (192.168.4.1) or a dedicated isolated management VLAN.
  • Credential Protection: The default installer PIN/password is uniquely generated during provisioning and printed on the device cryptographic label; default passwords (like admin/admin) are prohibited.
  • Brute-Force Lockout: Five consecutive invalid authentication attempts trigger an escalating lockout delay (up to 15 minutes) and generate a security alarm entry in the diagnostics log.