Chiavi WireGuard su ESP32: per dispositivo o una sola incorporata?

Lo schizzo mette la chiave privata di WireGuard in un array di caratteri, e il tunnel funziona, per questo la domanda torna sempre. La decisione che dovete davvero prendere non è «è sicuro» ma «quale delle tre condizioni vale per questa distribuzione». Sono: chi può tenere fisicamente il dispositivo, cosa dà una lettura della flash sul vostro componente, e se la flotta condivide una chiave o ne porta una ciascuno. Rispondete e il progetto segue, perché ogni condizione cambia il costo di una chiave trapelata, non il fatto che possa trapelare.

Cosa autorizza la chiave

WireGuard autentica i peer con la chiave pubblica. Il server associa la chiave pubblica di ogni peer a un indirizzo e a un AllowedIPs elenco, quindi è la chiave privata che permette a un client di inviare traffico da quell’indirizzo.

La stessa voce decide quali destinazioni il dispositivo può raggiungere, quindi una chiave trapelata espone la rete dietro il tunnel oltre all’indirizzo del tunnel.

Prima condizione: chi può tenere il dispositivo

Se l’unità vive in un armadio chiuso e nessuno fuori dal vostro team la tocca, l’esposizione è soprattutto una questione di distribuzione del firmware. Se viene spedita ai clienti, sta in un veicolo o torna in garanzia, il possesso fisico è la credenziale e la segretezza del binario è secondaria. Chi tiene il dispositivo non deve leggere la chiave, perché il firmware in esecuzione gli aprirà il tunnel. Per questo la risposta lato server deve includere revoca e una durata di vita limitata, non solo un’immagine protetta.

Decidete questa condizione prima delle altre due, perché fissa il budget per entrambe.

Seconda condizione: cosa dà una lettura della flash

Chiunque possa leggere l’immagine della flash recupera una chiave memorizzata come letterale, che sia tramite una connessione di debug, un file di aggiornamento, un backup o un’unità restituita. La cifratura della flash aumenta il costo di un dump diretto, e la documentazione ESP-IDF descrive cosa copre la funzione per un dato componente e una data configurazione. Non impedisce l’estrazione della chiave in ogni modello di attacco, e non fa nulla per il caso del dispositivo in mano. Trattatela come uno strato che cambia il costo, non come la risposta.

Leggete la documentazione della piattaforma per il vostro chip e la vostra configurazione esatti prima di affermare una proprietà in una revisione di progetto.

Terza condizione: riuso su tutta la flotta

Una chiave per una serie di produzione significa che ogni unità condivide un’identità. Il server non può distinguerle nei log, non può revocarne una senza revocarle tutte, e non può distinguere un clone da un originale. Le chiavi per dispositivo risolvono tutte e tre, al costo di un passo di registrazione e di una mappatura dal numero di serie alla chiave pubblica. Quella mappatura è l’asset che trasforma la revoca in una modifica di una riga invece di un reflash dell’intera flotta.

Se la flotta è di cinque unità su un banco, condividere una chiave può essere uno scambio ragionevole. Se è di cinquecento sul campo, non è affatto uno scambio.

Lo schema di registrazione che rende praticabili le chiavi per dispositivo

Generate la coppia di chiavi sul dispositivo al primo avvio, tenete la metà privata in memoria non volatile protetta e inviate solo la chiave pubblica a un servizio di registrazione che assegna un indirizzo e scrive la voce di peer. Autenticate la risposta di registrazione, altrimenti un attaccante sulla rete locale può registrare la propria chiave sul vostro account. Non stampate mai la chiave privata sulla console seriale durante il provisioning. Annotate il numero di serie del dispositivo accanto alla chiave pubblica, così un’unità persa corrisponde esattamente a una voce di peer.

È un servizio piccolo, ed è la differenza tra una flotta che potete verificare e una flotta che potete solo riflashare.

Tempo, endpoint e la decisione

L’esempio sincronizza l’ora prima di avviare il tunnel, e questo conta oltre TLS: gli handshake di WireGuard portano un timestamp per la protezione contro la ripetizione, quindi un dispositivo che si avvia con l’orologio sbagliato può vedere handshake rifiutati. L’endpoint è un nome host, il che mette il DNS nel percorso di fiducia anche se la chiave pubblica del server autentica ancora il peer. Un indirizzo sbagliato spreca tentativi e rivela quando il dispositivo è online. Risolvete entrambe le cose prima di discutere della chiave.

Poi decidete: una chiave condivisa solo finché il possesso è controllato e la flotta è piccola, chiavi per dispositivo non appena una delle due smette di essere vera.