14.4.6. Operazioni: chiavi, scadenza e risoluzione dei problemi

Tre aspetti della gestione dei certificati riguardano ogni dispositivo distribuito: proteggere la chiave privata una volta che si trova sulla camera, pianificare il giorno in cui il certificato scadrà e la breve lista di modalità di errore che si presentano nella pratica.

14.4.6.1. Proteggere la chiave privata

Ogni volta che la camera presenta un certificato – come server TLS o come client in mTLS – la sua chiave privata deve risiedere sul dispositivo, in formato DER non cifrato, sul filesystem o in ROMFS. Memorizzata in questo modo, è leggibile da qualsiasi codice in esecuzione sulla camera e da chiunque vi abbia accesso fisico: l’unità di archiviazione di massa USB, un prompt REPL o la flash grezza. ROMFS e i flag di sola lettura impediscono la modifica, non l”estrazione. Considera qualsiasi chiave privata distribuita su un dispositivo come recuperabile da un attaccante determinato con accesso fisico o al codice.

Questo non rende il TLS inutile – modella il modo in cui lo distribuisci:

• Usa una chiave e un certificato univoci per ogni dispositivo. Non programmare mai una singola chiave condivisa sull’intero parco dispositivi: estrarla da una singola unità permetterebbe a un attaccante di impersonare ogni camera. Le chiavi per-dispositivo limitano una compromissione a quel solo dispositivo, che puoi revocare o disabilitare lato server.

• Mantieni i certificati di breve durata. Una chiave rubata è utile solo finché il suo certificato è valido; durate brevi più una rotazione regolare limitano i danni (vedi Scadenza e rotazione dei certificati più avanti).

• Evita del tutto di mettere un segreto sul dispositivo quando puoi. Se devi solo verificare il server (autenticazione del server, non mTLS), la camera come client memorizza solo il certificato CA – che è pubblico – e non detiene alcuna chiave privata che valga la pena rubare.

• Non distribuire mai una chiave in un’immagine firmware pubblica. Una chiave incorporata in ROMFS in una build del firmware che distribuisci non è segreta; chiunque scarichi il firmware la possiede. Il provisioning per-dispositivo significa programmare la chiave dopo il firmware generico, non al suo interno.

• Limita il raggio d’azione. Restringi l’ambito di ciò che il certificato autentica (privilegio minimo) e assicurati che una singola identità di dispositivo trapelata possa essere revocata o disabilitata senza compromettere il resto.

Se il tuo modello di minaccia include attaccanti con accesso fisico, progetta partendo dal presupposto che la chiave del dispositivo prima o poi trapelerà e rendi questa eventualità sopravvivibile, invece di assumere che possa essere mantenuta segreta su hardware che non dispone di alcun mezzo per farlo.

14.4.6.2. Scadenza e rotazione dei certificati

Ogni certificato porta con sé una finestra di validità. Una volta superata, un peer ssl.CERT_REQUIRED rifiuta la connessione – quindi la scadenza è un’interruzione reale e programmata, non un rischio teorico. Anche l’orologio della camera deve essere corretto affinché il controllo di validità venga valutato onestamente.

• Autofirmato. Hai scelto la durata con -days. Quando scade devi rigenerare la chiave/il certificato e ridistribuirlo: ricopia i file DER, oppure ricompila e riprogramma l’immagine ROMFS se il certificato è incorporato. Scegli un valore -days su cui ti ricorderai effettivamente di agire.

• CA pubblica. Questi sono deliberatamente di breve durata. Let’s Encrypt emette certificati di 90 giorni e si aspetta un rinnovo automatico all’incirca ogni 60 giorni; non esiste un’opzione «installa una volta e dimentica».

La tendenza più ampia è unidirezionale: la validità massima dei certificati TLS attendibili pubblicamente continua a ridursi. Era di 825 giorni, attualmente è limitata a 398 giorni e il CA/Browser Forum ha adottato un calendario che la riduce gradualmente fino a circa 47 giorni entro il 2029. La conclusione per la progettazione di un dispositivo è di assumere che i certificati siano di breve durata e che la rotazione debba essere automatizzata o almeno regolare – non distribuire un prodotto che dipenda da un essere umano che sostituisce un certificato di dieci anni.

In pratica, sulla camera: preferisci progetti in cui il certificato possa essere sostituito senza riprogrammare (un filesystem scrivibile più un percorso di aggiornamento remoto, oppure eseguire la camera come client che si fida di una CA che ruoti centralmente). Se un certificato deve risiedere in ROMFS, pianifica gli aggiornamenti del firmware in base alla sua durata.

14.4.6.3. Risoluzione dei problemi

• L’orologio deve essere impostato. Una camera che non ha impostato il proprio orologio dall’accensione non supera il controllo di validità del certificato – chiama prima ntptime.settime().

• Il nome host deve corrispondere. Quando il client passa server_hostname esso deve corrispondere al subjectAltName del certificato (o al CN sugli stack più datati), altrimenti la verifica fallisce.

• Formato errato. Un file PEM copiato sulla camera non verrà caricato – convertilo prima in DER.

• Certificato scaduto. Una connessione che funzionava prima e ora fallisce con OSError potrebbe avere semplicemente un certificato scaduto – controlla le date di validità e rigenera/ridistribuisci secondo necessità.

• Le chiavi Ed25519 falliscono. Usa ECDSA P-256/P-384 o RSA, non Ed25519.

• Gli errori sono OSError. MicroPython non implementa ssl.SSLError; i fallimenti TLS (certificato non valido, scaduto, CA sconosciuta, errore di formato, fallimento dell’handshake) vengono sollevati come OSError.