Tecnologia

Architettura, sicurezza, validazione.
Tecnologia scritta.

In attesa dei dati live…

Architettura

S451 si regge su quattro componenti che dialogano fra loro: una mesh WireGuard® di connettività, un cluster NATS di messaggistica, un layer di persistenza per chiavi, configurazioni e stato della flotta, e un daemon Rust che vive sui dispositivi. L'intera infrastruttura è gestita in modo dichiarativo ed è facilmente replicabile. Gira su container rootless ed è hardenizzata a livello systemd con confini stretti su capacità, namespace, syscall.

WireGuard®

Tutta la connettività interna fra i server M4SS, i server dei clienti e i dispositivi sul campo passa da un'unica mesh WireGuard®, governata da un controllore centrale. Ogni nodo ha il suo client di mesh, si autentica al controllore e riceve la propria configurazione di rete cifrata. SSH, HTTP e qualsiasi altro protocollo IP fra i nodi M4SS viaggiano sempre dentro un tunnel cifrato, ovunque siano i nodi nel mondo.

NATS

Il broker NATS è in cluster su tre regioni cloud indipendenti (Hetzner Norimberga, Scaleway Parigi, Scaleway Milano), così la perdita di un singolo data center non ferma la piattaforma. Davanti al cluster gira compressed-nats, un proxy in Rust scritto da M4SS che termina il TLS e applica compressione zstd: meno banda consumata sul lato dispositivo, minore latenza, costo inferiore per il cliente. NATS fa anche da archivio live per le configurazioni dei dispositivi e da layer di controllo degli accessi che tiene isolati fra loro i progetti dei clienti - la base della multi-tenancy di S451.

Persistenza

Un componente in Rust gestisce la persistenza delle chiavi crittografiche, delle configurazioni dei dispositivi e dello stato della flotta. Il PostgreSQL lo gestiamo noi, su VPS e server dedicati, con Patroni per l'alta disponibilità e pgbackrest per backup e disaster recovery; i backup vengono replicati su più provider indipendenti, in modo che nessun singolo fornitore possa metterli a rischio. L'intero layer di storage è costruito su primitive open source che operiamo direttamente, senza un'astrazione di database managed fra noi e i dati.

Edge

Su ogni dispositivo gira un daemon scritto in Rust, integrato nella distribuzione M4SS Linux Embedded Machine (layer Yocto meta-m4ss). Gestisce il bootstrap, la rotazione delle chiavi, la lettura delle configurazioni dal Key-Value Store, l'applicazione degli aggiornamenti OTA, l'aggancio alla mesh WireGuard®. A valle del gateway, attraverso la rete radio M4SS via CDM, si trovano i sensori e gli attuatori del cliente.

Sicurezza

Le quattro proprietà di sicurezza qui sotto sono parte di S451 dalla revisione architetturale del 2022/2023 (vedi Validazione esterna) e sono state preservate nell'architettura attuale.

Cifratura end-to-end anche dentro il broker

Ogni messaggio è cifrato in modo ibrido: una chiave simmetrica AES, generata per ogni comunicazione, è a sua volta cifrata con la chiave pubblica RSA del destinatario. Solo chi possiede la chiave privata corrispondente può leggere il payload, anche se il broker stesso fosse compromesso. Il TLS in transito è un livello aggiuntivo, non l'unico.

Rotazione automatica delle chiavi

Le chiavi RSA dei dispositivi e del componente cloud che le distribuisce si rinnovano in modo automatico, senza intervento dell'utilizzatore. È prassi crittografica solida, ed è in linea con quanto il Cyber Resilience Act chiede ai prodotti con elementi digitali.

Bootstrap a prova di clone

Ogni dispositivo nasce con una chiave privata propria, generata in fabbrica. Per entrare in S451 il dispositivo deve dimostrare di possedere quella chiave, con uno schema challenge-response a firma digitale verso la Edge API. Clonare il firmware non replica la chiave privata del singolo dispositivo: nessun clone riesce ad autenticarsi.

Aggiornamenti A/B con rollback automatico

Ogni dispositivo ha quattro partizioni: bootloader, live, rollback, data. Ogni nuovo aggiornamento OTA viene scritto sulla partizione di rollback e diventa la nuova partizione live al riavvio. Se il sistema rileva malfunzionamenti dopo l'aggiornamento, un daemon dedicato inverte l'ordine di boot e riporta il dispositivo alla versione precedente. Senza intervento umano.

Validazione

S451 è validata costantemente, nella pratica. La sicurezza non è solo teoria.

Tesi sperimentale

L'evoluzione di S451 verso l'architettura attuale ha avuto una tappa documentata in una tesi sperimentale del Dipartimento di Scienze Fisiche, Informatiche e Matematiche dell'Università di Modena e Reggio Emilia.

Studio e Sviluppo di Aggiornamenti Sicuri IIoT con Tecnologia S451
Anno Accademico 2022/2023. Candidato: Manuel Pelloni. Relatore: Prof. Luca Bedogni. Correlatori: Paolo Barbolini, Davide Gullo.

La tesi descrive nel dettaglio le quattro proprietà di sicurezza qui sopra, che sono diventate il fondamento dell'architettura attuale. Per noi è prova sul campo che la metodologia regge anche a una revisione indipendente.

Cura del codice che usiamo

S451 gira su molto codice open source che non abbiamo scritto noi. Non possiamo finanziare tutti i maintainer che tengono in vita quel codice - non ancora - ma possiamo leggere quello che usiamo e segnalare ciò che non va. Sei advisory formali sul registro rustsec/advisory-db, la base dati che alimenta cargo audit e l'intero stack di dependency-scanning Rust. Coprono tre classi tecniche distinte: MitM TLS sui client NATS, unsoundness in unsafe su ruzstd, maxminddb e lru, più una follow-up. In più casi non ci limitiamo al ruolo di reporter: scriviamo il fix a monte e lo propaghiamo nei consumer critici. Il caso ruzstd è esemplare: in 24 ore sono stati tutti merged il fix nella libreria, la disclosure formale e il bump dentro rust-lang/rust (che usa ruzstd per i metadata delle crate).

Contributi a monte

Audit e disclosure sono una direzione; l'altra è la contribuzione. Sul registro pubblico GitHub ci sono 1.108 pull request merged su 252 repository distinti, con un merge-rate dell'87,7%: tasso significativo perché si tratta in larga parte di contributi esterni, validati dai maintainer dei progetti target. Feature, fix, ottimizzazioni, dependency-bump che propagano patch RustSec note. Le aree toccate sono i nodi load-bearing dello stack Rust: TLS (rustls, hyper-rustls), HTTP (hyper, reqwest), database (sqlx, rust-postgres), runtime (tokio, bytes), il registry ufficiale (crates.io) e il compilatore stesso (rust-lang/rust). Co-manuteniamo lettre, il client SMTP+TLS standard di Rust (281 PR merged).

Open source

S451 è una piattaforma proprietaria. I suoi mattoni che possono essere utili all'intera comunità Rust e IIoT diventano open source. Il primo è già pubblicato.

Watermelon

Il client NATS pure-Rust scritto da M4SS. L'abbiamo sviluppato perché ci serviva un client NATS che potessimo controllare e verificare end-to-end, allo standard di qualità che pretendiamo dal codice in produzione su S451. Offerto alla comunità Rust come opzione indipendente, rilasciato sotto licenza open source. Repository: github.com/M4SS-Code/watermelon.

Altri componenti, dove abbia senso strategico per la comunità, seguiranno. Il dettaglio del lavoro open source di M4SS, con i numeri e i progetti, vive su m4ss.net/attivita/open-source.

Contattaci

Compila il form per maggiori informazioni