Technology
Architecture, security, validation.
Engineering you can read.
In attesa dei dati live…
Architecture
Four components, one conversation: a WireGuard® mesh, a NATS cluster, a Rust persistence layer for keys, configurations and fleet state, and a Rust daemon on every device. Declarative infrastructure, easy to replicate. Rootless containers, hardened at the systemd level with tight bounds on capabilities, namespaces and syscalls.
WireGuard®
One WireGuard® mesh links M4SS servers, customer servers and field devices, governed by a central controller. Every node authenticates and pulls its encrypted network config. SSH, HTTP and any other IP traffic between M4SS nodes travels inside an encrypted tunnel, anywhere in the world.
NATS
The NATS broker is clustered across three independent cloud regions (Hetzner Nuremberg, Scaleway Paris, Scaleway Milan). Lose a data center, the platform stays up. In front of it sits compressed-nats, an M4SS Rust proxy that terminates TLS and applies zstd compression: less bandwidth on the device side, lower latency, lower cost. NATS also acts as the live store for device configurations and as the access-control layer that keeps customer projects isolated. The backbone of S451 multi-tenancy.
Persistence
A Rust component persists cryptographic keys, device configurations and fleet state. We run PostgreSQL ourselves on VPS and dedicated servers: Patroni for high availability, pgbackrest for backup and disaster recovery. Backups are replicated across independent providers so no single vendor can take them out. Open-source primitives we operate directly. No managed-database abstraction between us and the data.
Edge
Every device runs a Rust daemon, shipped in the M4SS Linux Embedded Machine distribution (Yocto layer meta-m4ss). It handles bootstrap, key rotation, config reads from the Key-Value Store, OTA updates and joining the WireGuard® mesh. Past the gateway, the customer's sensors and actuators run on the M4SS radio network via CDM.
Security
The four properties below have been part of S451 since the 2022/2023 architectural review (see External validation) and remain core to the current architecture.
End-to-end encryption inside the broker
Every message is hybrid-encrypted: a fresh AES key per communication, sealed with the recipient's RSA public key. Only the matching private key reads the payload. A compromised broker reads nothing. TLS in transit is an extra layer, not the only one.
Automatic key rotation
Device and cloud RSA keys rotate automatically. No operator intervention. Standard cryptographic practice, aligned with what the Cyber Resilience Act expects of products with digital elements.
Clone-proof bootstrap
Every device ships with its own private key, generated at the factory. To join S451 it must prove possession through a signature-based challenge from the Edge API. Clone the firmware and the per-device key doesn't come with it. No clone authenticates.
A/B updates with automatic rollback
Four partitions per device: bootloader, live, rollback, data. OTA updates land on the rollback partition and become live at next boot. If the device misbehaves afterwards, a dedicated daemon flips the boot order back. No human in the loop.
Validation
S451 is validated continuously, in practice. Not just on paper.
Experimental thesis
A milestone in S451's path to the current architecture is documented in an experimental thesis at the Department of Physical, Computer and Mathematical Sciences, University of Modena and Reggio Emilia.
Study and Development of Secure IIoT Updates with S451 Technology
Academic year 2022/2023. Candidate: Manuel Pelloni. Supervisor: Prof. Luca Bedogni. Co-supervisors: Paolo Barbolini, Davide Gullo.
It documents the four security properties above in detail. They are the foundation of the current architecture. For us, field evidence that the methodology holds up under independent review.
Care for the code we depend on
S451 runs on a lot of open-source Rust we didn't write. We can't fund every maintainer yet, but we can read what we depend on and report what's wrong. Six formal advisories on the rustsec/advisory-db registry, the database that powers cargo audit and the Rust dependency-scanning stack. Three classes: TLS MitM in NATS clients, unsafe unsoundness in ruzstd, maxminddb and lru, plus one follow-up. We often go past the reporter role and write the upstream fix, then push it into critical consumers. The ruzstd case is exemplary: in 24 hours we merged the library fix, the formal disclosure, and the bump inside rust-lang/rust (which uses ruzstd to decompress crate metadata).
Contributing back
Audit is one direction. Contribution is the other. The public GitHub record: 1,108 merged pull requests across 252 distinct repositories, 87.7% merge rate. Most of those PRs are external, validated by the target projects' maintainers. Features, fixes, performance work, dependency bumps that propagate RustSec patches. The areas we touch are load-bearing: TLS (rustls, hyper-rustls), HTTP (hyper, reqwest), databases (sqlx, rust-postgres), runtime (tokio, bytes), the registry (crates.io) and the compiler itself (rust-lang/rust). We co-maintain lettre, the standard Rust SMTP+TLS client (281 merged PRs).
Open source
S451 is proprietary. The building blocks useful to the wider Rust and IIoT community ship as open source. The first one is already live.
Watermelon
M4SS's pure-Rust NATS client. We built it because we needed a NATS client we could fully audit, at the quality bar we hold for S451 production code. Open source, offered to the Rust community as an independent option. Repository: github.com/M4SS-Code/watermelon.
More components will follow where it makes sense for the community. The full picture of M4SS's open-source work, with numbers and projects: m4ss.net/attivita/open-source.
Contacts
Fill in the form for more information