Robotica
Cybersicurezza per la robotica: robot ROS 2 e droni
La cybersicurezza per la robotica è la protezione del software, del firmware, delle comunicazioni e del canale di aggiornamento di un robot o di un drone da attacchi che potrebbero esporre dati o causare comportamenti pericolosi. Per un robot ROS 2 o un drone significa imporre SROS 2 sul traffico DDS, mantenere aggiornato il firmware del companion computer e del controllore di volo e tenere traccia di ogni pacchetto di terze parti che distribuisci.
Piano Free, nessuna carta richiesta.
Qual è la superficie di attacco di un robot o di un drone?
Un robot moderno è un piccolo sistema distribuito su ruote, gambe o eliche: un controllore in tempo reale per il movimento e le funzioni di sicurezza, un companion computer per la percezione e la connettività, un middleware che collega i processi, collegamenti radio e un meccanismo di aggiornamento. Ogni livello porta con sé codice di terze parti, e ogni confine tra livelli è un’interfaccia che un attaccante può provare a sfruttare.
- Middleware: i nodi ROS 2 si scambiano messaggi tramite DDS. Senza la sicurezza attivata, i partecipanti non sono autenticati, quindi qualsiasi cosa si trovi sulla stessa rete e nello stesso dominio DDS può leggere i topic e pubblicare messaggi.
- Companion computer: di solito Linux, con kernel, librerie di sistema, servizi di rete e accesso remoto che vanno tutti aggiornati con le patch.
- Controllori di volo: PX4 gira principalmente sul sistema operativo in tempo reale NuttX sulle schede di controllo del volo; ArduPilot gira su ChibiOS su schede basate su STM32 e supporta anche schede basate su Linux.
- Collegamenti di telemetria: MAVLink collega controllori di volo, companion computer e stazioni di terra. La firma dei messaggi di MAVLink 2 permette a un sistema di verificare che i messaggi provengano da una fonte attendibile, ma non li cifra.
- Aggiornamenti over-the-air: un canale di aggiornamento non protetto permette a un attaccante di installare codice malevolo su ogni unità.
- Pacchetti di terze parti: pacchetti ROS, librerie Python e C++, immagini container e driver dei fornitori che non hai scritto tu ma che distribuisci.
Come funziona la sicurezza di ROS 2 (SROS 2)?
La sicurezza di ROS 2 si basa sulla specifica DDS-Security. La documentazione di progettazione di ROS 2 descrive tre plugin in uso: l’autenticazione di ogni partecipante con certificati X.509 firmati da un’autorità di certificazione di cui ti fidi; il controllo degli accessi, in cui file di governance e di permessi firmati definiscono come è protetto il dominio e quali topic ogni partecipante può leggere o scrivere; e un plugin crittografico che fornisce cifratura autenticata con AES-GCM. Il supporto a runtime e gli strumenti si chiamano Secure ROS 2 (SROS 2), e i file di sicurezza sono organizzati per enclave in un keystore.
Il dettaglio che conta di più nella pratica: per impostazione predefinita, nessuna di queste funzionalità è attiva. La sicurezza si attiva con la variabile d’ambiente ROS_SECURITY_ENABLE e, a meno che ROS_SECURITY_STRATEGY non sia impostata su Enforce, un processo che non trova i propri file di sicurezza si avvia senza sicurezza invece di fallire. Per un prodotto, usa Enforce, gestisci le autorità di certificazione e le chiavi private come qualsiasi altro segreto di produzione e rivedi i permessi ogni volta che aggiungi nodi, così che il driver di una telecamera non possa pubblicare comandi di velocità.
Sicurezza del firmware dei droni: controllori di volo, companion computer e aggiornamenti
La sicurezza del firmware dei droni segue la divisione dell’hardware. Il controllore di volo esegue l’autopilota su un microcontrollore con un sistema operativo in tempo reale. Il companion computer somiglia di più a un piccolo server e comunica con il controllore di volo tramite MAVLink oppure, con PX4, anche tramite uXRCE-DDS per ROS 2. Trattali come due prodotti distinti: toolchain, percorsi di aggiornamento e modi di elencare i componenti sono diversi.
In entrambi i casi i controlli sono quelli noti. Conosci i componenti e le versioni esatti di ogni build; firma il firmware e verifica le firme prima dell’installazione; blocca le interfacce di debug e i bootloader; e tieni traccia di quale versione firmware gira su quale velivolo. Sui collegamenti radio, attiva la firma dei messaggi di MAVLink 2 dove è supportata.
Il Cyber Resilience Act si applica a robot e droni?
Il CRA si applica ai prodotti con elementi digitali messi a disposizione sul mercato dell’UE la cui finalità prevista o il cui uso ragionevolmente prevedibile comprende una connessione dati diretta o indiretta a un dispositivo o a una rete. Un robot o un drone con una connessione di questo tipo rientrerà di solito in questa definizione, salvo che si applichi un’esclusione. Ciò comporta i requisiti essenziali dell’allegato I e la gestione delle vulnerabilità per i prodotti immessi sul mercato dall’11 dicembre 2027 e, dall’11 settembre 2026, l’obbligo previsto dall’articolo 14 di segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi. Il CRA non si applica ai prodotti certificati in conformità del regolamento (UE) 2018/1139, il regolamento dell’UE sulla sicurezza aerea, quindi verifica la posizione di ogni modello di drone.
Chi costruisce robot incontra di solito una seconda legge: il regolamento macchine, regolamento (UE) 2023/1230, che si applica dal 20 gennaio 2027 e comprende requisiti di sicurezza sulla protezione dall’alterazione e su sistemi di comando in grado di resistere a tentativi deliberati da parte di terzi. Il considerando 53 del CRA afferma che rispettare il CRA potrebbe facilitare la conformità a tali requisiti, ma è il fabbricante a doverne dimostrare il collegamento. Il regolamento macchine esclude i mezzi di trasporto per via aerea e i prodotti aeronautici disciplinati dal regolamento (UE) 2018/1139, nella misura in cui tale regolamento disciplina i requisiti pertinenti, quindi verifica come entrambe le esclusioni si applicano a un drone.
Proteggere i pacchetti ROS e le dipendenze di terze parti
Il software dei robot si assembla a partire da ecosistemi: pacchetti ROS dichiarati in package.xml, dipendenze di sistema risolte tramite chiavi rosdep, repository sorgente scaricati con file .repos di vcstool, librerie Python e C++ e la distribuzione Linux sottostante. Il CRA richiede la dovuta diligenza sui componenti di terzi, compresi quelli open source (articolo 13, paragrafo 5), e una SBOM che includa almeno le dipendenze di primo livello (allegato I, parte II). In pratica, devi sapere quali versioni sono finite nell’immagine che hai distribuito, non solo quelle richieste dal workspace.
Passi pratici: fissa le versioni nei file rosdep e .repos; genera la SBOM dall’immagine o dal container compilati, non solo dai manifest dei sorgenti; segui gli avvisi di sicurezza della tua implementazione DDS e della tua distribuzione Linux; tieni d’occhio la data di fine vita della distribuzione ROS 2 su cui sviluppi; e assegna a ogni modello di robot un periodo di assistenza e un percorso di aggiornamento che puoi davvero garantire per tutta la sua vita utile.
Disponibile oggi in KROMSE
Oggi KROMSE copre diversi livelli del software di un robot; i dati sulle vulnerabilità specifici per la robotica sono ancora nella roadmap.
- I manifest dei pacchetti ROS (package.xml, chiavi rosdep, file .repos di vcstool) vengono elencati nell’inventario; la maggior parte non viene ancora confrontata con gli avvisi di sicurezza, tranne i componenti fissati a un commit o a un tag su una forge pubblica o dotati di un identificatore di pacchetto PyPI, npm, crates.io o Go.
- Le dipendenze dei nodi ROS vengono confrontate con OSV.dev quando esiste un lockfile o un manifest supportato, come i requirements di pip, Poetry o uv per Python. I file di build C++ come CMake, Conan e vcpkg vengono elencati e, per la maggior parte, non ancora confrontati con gli avvisi di sicurezza.
- Analisi del codice sorgente per 11 linguaggi, tra cui C, C++ e Python.
- Le immagini firmware Linux dei companion computer, fino a 512 MB, vengono estratte; pacchetti e binari vengono controllati per individuare vulnerabilità note, e il file system root viene controllato anche per errori di configurazione e segreti.
- I file .px4 di PX4 vengono spacchettati e scansionati come gli altri firmware, ma i componenti NuttX al loro interno non vengono ancora identificati.
- Le immagini container in un registry raggiungibile da internet, come le immagini in cui girano i tuoi nodi ROS 2, vengono analizzate per individuare vulnerabilità, errori di configurazione e segreti.
In arrivo
Nella roadmap, non ancora disponibile. Le date sono obiettivi, non promesse; questa pagina viene aggiornata il giorno in cui una funzionalità diventa disponibile.
- In arrivo · Q4 2026 (dicembre)Sicurezza per la robotica. KROMSE aggiungerà gli avvisi di sicurezza per ROS 2, l’identificazione dei componenti all’interno dei firmware PX4 e ArduPilot e dati sulle vulnerabilità specifici per i robot.
- In arrivo · Q1 2027Firmware bare-metal e RTOS. KROMSE identificherà i componenti nei firmware privi di un file system Linux, come le immagini bare-metal e RTOS basate su FreeRTOS o Zephyr.
- In arrivo · Q1 2027Evidenze per il regolamento macchine. KROMSE raccoglierà le evidenze per i requisiti di cibersicurezza del regolamento macchine (UE) 2023/1230, accanto al fascicolo CRA del tuo prodotto.
Domande frequenti
ROS 2 è sicuro per impostazione predefinita?
No. ROS 2 può usare DDS-Security per autenticazione, controllo degli accessi e cifratura tramite SROS 2, ma la documentazione di progettazione di ROS 2 afferma che nessuna di queste funzionalità di sicurezza è attiva per impostazione predefinita. Le attivi con ROS_SECURITY_ENABLE, e dovresti impostare ROS_SECURITY_STRATEGY su Enforce, così che un nodo senza file di sicurezza validi non si avvii invece di funzionare senza protezione.
Che cos’è SROS 2?
SROS 2, o Secure ROS 2, è l’insieme di funzionalità e strumenti che rendono disponibile DDS-Security in ROS 2. Usa certificati X.509 per l’autenticazione, file di governance e di permessi firmati per il controllo degli accessi e AES-GCM per la cifratura autenticata, con i file di sicurezza archiviati per enclave in un keystore. La progettazione di ROS 2 descrive anche uno strumento a riga di comando, ros2 security, per generare questi file.
Il Cyber Resilience Act si applica ai droni?
Può applicarsi. Il CRA riguarda i prodotti con elementi digitali che hanno una connessione dati a un dispositivo o a una rete, il che include molti droni, ma non si applica ai prodotti certificati in conformità del regolamento (UE) 2018/1139, il regolamento dell’UE sulla sicurezza aerea. Se un determinato drone sia escluso dipende dalla sua certificazione. KROMSE non stabilisce se una legge si applica, quindi verifica la posizione per ogni modello.
KROMSE può scansionare firmware PX4 o ArduPilot?
In parte. I file .px4 di PX4 vengono spacchettati e scansionati come gli altri firmware, ma i componenti NuttX al loro interno non vengono ancora identificati, quindi il risultato è limitato. Il firmware ArduPilot e le altre immagini bare-metal o RTOS oggi non sono supportati. Le immagini dei companion computer basate su Linux fino a 512 MB vengono estratte e scansionate. L’identificazione dei componenti per PX4 e ArduPilot è nella roadmap.
Cosa dovrebbe preparare per primo un costruttore di robot in vista del CRA?
Parti da un inventario: una SBOM per ogni modello di robot e versione firmware rilasciati, che copra il companion computer, il firmware del controllore e il workspace ROS. Poi definisci un periodo di assistenza, un percorso di aggiornamento firmato che puoi garantire per quel periodo, una politica di divulgazione coordinata delle vulnerabilità con un indirizzo di contatto e un processo per segnalare le vulnerabilità attivamente sfruttate entro 24 ore da quando ne vieni a conoscenza.
Guide correlate
Fonti
- ROS 2 design: integrazione di DDS-Security in ROS 2
- Documentazione di ROS 2: distribuzioni a fine vita
- Documentazione di PX4: panoramica dell’architettura
- Documentazione di PX4: companion computer
- Documentazione per sviluppatori di ArduPilot: introduzione
- MAVLink: firma dei messaggi
- Regolamento (UE) 2024/2847 (regolamento sulla ciberresilienza), EUR-Lex
- Regolamento (UE) 2023/1230 relativo alle macchine (regolamento macchine), EUR-Lex