Satellite IoT for Remote Asset Monitoring: Designing a Secure Message Protocol Over Iridium SBD

Srihari Maddula • Founder & Technical Lead, Eurth Techtronics Pvt Ltd 

Category: Connectivity Reliability 

Estimated Reading Time: 9 min

A remote industrial site — far enough from any cellular tower or LoRaWAN gateway coverage that terrestrial connectivity simply isn't an option — still needs its sensor data to reach a central monitoring location, reliably and securely. Satellite communication is the obvious answer to the reachability problem and a genuinely non-obvious engineering problem once security and cost enter the picture, because satellite airtime is expensive per byte in a way terrestrial connectivity isn't, and a naive "just send the data over satellite" approach produces a system that's either prohibitively expensive to operate or insufficiently secure for anything beyond casual telemetry. This post covers the actual protocol design for exactly this problem, built around Iridium Short Burst Data (SBD) as the satellite transport.

Overview: Why Satellite Changes the Design Constraints

Iridium SBD is a genuinely different transport from terrestrial cellular or LPWAN — it's a message-oriented, low-bandwidth, per-message-cost satellite data service, with true global coverage including areas with zero terrestrial infrastructure, which is exactly the coverage profile a genuinely remote site needs. The design constraint that reshapes everything downstream is message size and cost: SBD messages have a hard size ceiling (typically up to 340 bytes per Mobile Originated message on standard hardware, with per-message cost that makes "just send more data to be safe" a real, recurring operating expense rather than a free design margin. Every byte in the message format has to justify its inclusion, and the security design specifically has to fit meaningful authentication and encryption into a budget that a terrestrial-connectivity engineer, used to essentially free bandwidth, will initially find uncomfortably tight.

Technical Details & Specifications: The Message Protocol

The protocol uses a compact binary frame — roughly 25-35 bytes for a typical sensor telemetry message, well within SBD's size ceiling with margin for authentication overhead — built around AES-128 or AES-256 in GCM mode (Galois/Counter Mode), which provides authenticated encryption: the message is both encrypted and cryptographically verified as unmodified and genuinely from the claimed sender, in a single operation, without needing separate encryption and authentication passes that would each add overhead this byte budget can't easily absorb.

// Compact binary telemetry frame -- every field justified against

// the tight SBD size/cost budget. Total frame size kept well under

// the 340-byte SBD ceiling to leave margin for AES-GCM overhead

// (nonce + authentication tag) and any future field additions.

typedef struct attribute((packed)) {

    uint32_t device_id;        // 4 bytes -- unique device identifier

    uint32_t sequence_num;     // 4 bytes -- monotonic counter, replay protection

    uint32_t timestamp;        // 4 bytes -- unix timestamp

    int16_t  temperature_c10;  // 2 bytes -- temp * 10, fixed-point to avoid float overhead

    uint16_t humidity_pct10;   // 2 bytes -- humidity * 10

    uint8_t  battery_pct;      // 1 byte

    uint8_t  status_flags;     // 1 byte -- bitfield: alarm, low-battery, sensor-fault, etc.

} telemetry_payload_t;         // 18 bytes plaintext payload

// AES-128-GCM encryption -- adds a 12-byte nonce and typically a

// 16-byte authentication tag, bringing total transmitted size to

// roughly 46 bytes -- comfortably within SBD's per-message limit

void encrypt_and_send(telemetry_payload_t payload, uint8_t device_psk) {

    uint8_t nonce[12];

    generate_nonce(nonce);  // unique per message -- critical for GCM security

    uint8_t ciphertext[sizeof(telemetry_payload_t)];

    uint8_t auth_tag[16];

    aes_gcm_encrypt(device_psk, nonce, (uint8_t*)payload,

                     sizeof(telemetry_payload_t), ciphertext, auth_tag);

    // Frame: nonce || ciphertext || auth_tag

    uint8_t sbd_frame[12 + sizeof(telemetry_payload_t) + 16];

    memcpy(sbd_frame, nonce, 12);

    memcpy(sbd_frame + 12, ciphertext, sizeof(telemetry_payload_t));

    memcpy(sbd_frame + 12 + sizeof(telemetry_payload_t), auth_tag, 16);

    iridium_sbd_transmit(sbd_frame, sizeof(sbd_frame));

}

Per-device pre-shared keys, provisioned at manufacturing time rather than negotiated over the air (which would itself cost precious SBD bandwidth and introduce key-exchange protocol complexity this transport isn't well suited for), are the practical key-management approach — each device carries a unique key burned in during production, with the central system maintaining the corresponding key-device mapping. The monotonic sequence counter provides replay protection: the receiving system tracks the last-seen sequence number per device and rejects any message with a sequence number at or below that watermark, preventing a captured, re-transmitted message from being accepted as new even though GCM's authentication alone wouldn't catch a pure replay of a validly-encrypted prior message.

Design element	Why it exists	Cost/trade-off
AES-GCM authenticated encryption	Single-pass confidentiality + integrity, minimal overhead	~28 bytes overhead (nonce + tag) per message
Per-device pre-shared key	Avoids over-the-air key exchange cost and complexity	Requires secure key provisioning at manufacturing, and a key-compromise response plan
Monotonic sequence counter	Replay protection beyond what GCM authentication alone provides	4 bytes per message; receiver must track last-seen sequence per device
Fixed-point sensor encoding	Avoids floating-point serialization overhead and ambiguity	Requires defining fixed-point scale/precision per field in advance

THE RULE:  GCM authentication alone proves a message is unmodified and genuinely from the claimed device — it does NOT prevent an attacker from re-transmitting a previously valid, captured message. Replay protection needs its own explicit mechanism, like the sequence counter here.

Advantages: What This Design Gets Right

The compact frame design, with every field deliberately fixed-point or bitfield-encoded rather than using a more general but verbose serialization format (JSON, for instance, would be wildly impractical at this byte budget), keeps the total message size — including full authenticated-encryption overhead — comfortably within SBD's per-message limit with real margin, which matters both for direct cost control and for resilience against future field additions without immediately hitting the size ceiling. The pre-shared key approach sidesteps a genuinely hard problem — public-key exchange over a transport this bandwidth-constrained — by moving key provisioning to manufacturing time, where it's a one-time, well-controlled process rather than a recurring over-the-air operation competing for the same scarce bandwidth as the actual telemetry data.

The Mobile-Terminated return path (satellite-to-device commands, not just device-to-satellite telemetry) enables key rotation and remote configuration changes without requiring physical device access — a genuinely important capability for a device deployed at a site that may be logistically difficult or expensive to physically visit, and one that's easy to underweight during initial design when the team is focused primarily on the outbound telemetry path.

Challenges & Trade-offs: What Satellite-First Costs

Per-message cost, unlike most terrestrial connectivity options, is a real, direct, per-transmission expense that scales linearly with reporting frequency — a device reporting every few minutes accumulates a materially different operating cost than one reporting hourly, and this needs to be modeled explicitly against the actual monitoring requirement's real urgency, not defaulted to "as frequently as possible" the way a team used to effectively-free cellular or WiFi bandwidth might reflexively default. The right reporting interval for a satellite-connected device is a genuine cost-versus-freshness trade-off decision, not a technical constant.

Pre-shared key provisioning, while it sidesteps the over-the-air key exchange problem, introduces its own operational challenge: a compromised key (from a captured device, or a manufacturing process breach) requires either remote key rotation via the Mobile-Terminated path — which itself needs to be designed securely, since a command channel that can update encryption keys is a high-value target for exactly the kind of attack the encryption exists to prevent — or physical device recovery, which for a genuinely remote deployment can be logistically difficult and expensive. The key rotation command path deserves at least as much security design attention as the primary telemetry path, and it's easy to underweight this as a secondary concern relative to the more visible telemetry data flow.

SBD's message-oriented, store-and-forward nature (rather than a persistent connection) means message delivery isn't instantaneous in the way a live cellular data connection is — there's a real, though generally modest, latency between transmission and delivery, and designing an alerting system around SBD needs to account for this latency explicitly rather than assuming near-real-time delivery the way a terrestrial-connected system might reasonably assume.

THE RULE:  The command channel that can rotate encryption keys or reconfigure a remote device deserves the same security scrutiny as the primary data path — it's a smaller, less visible attack surface, and smaller/less-visible is exactly the profile of an attack surface that gets under-scrutinized during design review.

Case Study: Sizing the Reporting Interval Against Real Cost

An early design pass for a representative remote-site monitoring deployment defaulted to a reporting interval carried over from a prior terrestrial-cellular-connected project — frequent enough to feel appropriately responsive for an environmental and equipment-health monitoring use case, but never actually re-evaluated against SBD's real per-message cost structure. Modeling the accumulated monthly cost at that carried-over interval against the actual, achievable urgency requirement (the monitored parameters — equipment temperature, structural sensor readings — genuinely didn't need minute-level freshness; hour-level freshness was entirely adequate for the actual use case) revealed the naive interval was generating a materially higher recurring operating cost than the monitoring requirement actually justified.

The fix — re-deriving the reporting interval from the actual monitoring requirement's real urgency rather than from habit carried over from a different transport's cost structure, combined with event-triggered out-of-cycle transmission for genuinely urgent readings (an alarm condition triggers an immediate message regardless of the normal periodic schedule, while routine readings stay on the longer, cost-optimized interval) — delivered both the cost reduction the naive interval was missing and, arguably, better actual responsiveness for the readings that genuinely mattered, since the alarm-triggered path bypassed the periodic schedule entirely rather than waiting for the next scheduled transmission. The broader lesson: transport-specific cost structures should drive transport-specific design decisions, and carrying an assumption over from a different transport's economics is a common, costly mistake when adopting satellite connectivity for the first time.

Implementation Plan: Designing a Satellite IoT Message Protocol

• Define the actual data fields needed and their real precision requirements before designing the wire format — use fixed-point or bitfield encoding rather than a verbose general-purpose serialization format, given the tight per-message size budget.

• Choose authenticated encryption (AES-GCM or equivalent) over separate encryption and authentication passes, to minimize per-message overhead against the size ceiling.

• Design replay protection explicitly (a sequence counter or timestamp-based mechanism) — don't assume authenticated encryption alone prevents message replay, because it doesn't.

• Provision per-device keys at manufacturing time rather than attempting over-the-air key exchange, and design the key-rotation command path with the same security rigor as the primary telemetry path from the start.

• Derive the reporting interval from the monitoring requirement's actual urgency and the transport's real per-message cost — not from habits carried over from a different, cheaper transport — and add event-triggered out-of-cycle transmission for genuinely urgent conditions rather than relying solely on the periodic schedule.

• Design the receiving system to track per-device sequence-number watermarks and reject stale/replayed messages, and to handle SBD's store-and-forward latency explicitly in any alerting logic rather than assuming near-instant delivery.

• Plan and test the full key-rotation flow (Mobile-Terminated command triggering a key update) before deployment, not as a theoretical capability — a compromised-key response plan that's never been tested is not a real response plan.

Conclusion: Satellite Connectivity Rewards Discipline That Terrestrial Connectivity Doesn't Demand

Every design decision covered here — compact binary framing, authenticated encryption with explicit replay protection, pre-shared keys with a genuinely secure rotation path, and a reporting interval derived from real cost and real urgency rather than habit — reflects the same underlying shift: satellite connectivity's real per-byte and per-message cost forces a level of protocol design discipline that cheap, abundant terrestrial bandwidth lets teams skip. A team bringing terrestrial-connectivity habits directly into a satellite IoT design, without re-deriving these decisions against SBD's actual constraints, produces a system that's either quietly expensive to operate or insufficiently secure — and the fix, in every case covered here, was going back to first principles for this specific transport rather than assuming a pattern that worked well on a different, more forgiving connectivity budget would transfer unchanged.

EurthTech delivers AI-powered embedded systems, IoT product engineering, and smart infrastructure solutions — Hyderabad, India. www.eurthtech.com