Poiché ci sono molte aziende cinesi che possono facilmente decodificare il progetto PCB ed estrarre il file .hex dai microcontrollori (anche da il flash sicuro), gli sviluppatori embedded devono aggiungere un po più di protezione ai loro prodotti. Nel mio caso sto usando un STM32F103 e voglio aggiungere il crypto IC ATSHA204A sul mio PCB per proteggere il mio IP. In questo modo, spero anche se riescono a estrarre il .hex dallMCU e clonare la scheda, il file hex si rifiuterà di funzionare se non è in grado di riconoscere il crypto chip sul PCB.
Questo crypto IC ha un numero di serie univoco che è stato scritto durante la produzione e può sempre essere letto. Ha anche alcune funzionalità come unarea sicura per mantenere alcuni dati segreti, la capacità di generare numeri casuali e inviarli allhost tramite I2C o one-wire, capacità di calcolare lhash SHA-256 di una determinata stringa e così via.
Ora sto cercando di capire come dovrei lavorare con esso dato che sono una specie di noob sullargomento dellautenticazione. Da quello che ho capito leggendo la scheda tecnica, il flusso di lavoro sarà il seguente:
Personalizzazione del crypto IC:
-
Larea sicura nel crypto il chip verrà riempito dallhost (STM32F103 nel mio caso) con una chiave segreta casuale per ogni prodotto, una sola volta.
-
La chiave segreta sarà presente anche nella flash degli host memoria.
Autenticazione della scheda (La mia comprensione, che probabilmente è sbagliata):
-
Lhost richiede un numero casuale dal crypto-IC. Quindi lhost genera una stringa concatenata con la chiave segreta e il numero casuale (nonce?), E calcola lhash SHA-256 di esso.
-
Ora lhost dovrebbe inviare il chiave casuale torna al crypto-IC e aspettati che generi la stessa stringa con la chiave segreta allinterno del crypto-IC e calcoli lhash SHA-256 di esso.
-
Crypto-IC restituisce lhash calcolato allhost e lhost confronta gli hash.
-
Se gli hash corrispondono, convalidare. Se non lo fanno, lhost si rifiuta di lavorare.
Il flusso di lavoro è probabilmente sbagliato, ma lidea principale dovrebbe essere qualcosa di simile. Qualcuno può spiegarlo?
Risposta
Il flusso di lavoro è probabilmente sbagliato, ma lidea principale dovrebbe essere qualcosa di simile.
No, questo è fondamentalmente inutile. Andrebbe bene se tu “utilizzassi il tuo crypto IC, ad esempio, per convalidare lautenticità di un dispositivo aggiuntivo (ad esempio, una stampante che verifica che la cartuccia sia stata prodotta dalla stessa azienda).
Non “ti aiuta , perché " si rifiuta di funzionare " non volerà se qualcuno ha il codice macchina del tuo firmware: trovare il segno di spunta nel codice macchina smontato di solito non è quello difficile. Quindi, è tanto quanto sostituire un " salto a “fermarsi e non fare nulla” " con un " passa a “start di funzionalità utili “"; in genere, ciò comporta la modifica di un byte.
È necessario crittografare la parte interessante del firmware nella memoria permanente (in genere, la flash incorporata dellMCU). Solo un bootloader che utilizza il chip crittografico per decrittografare il firmware principale rimarrebbe non crittografato. Allavvio, il bootloader decrittografa il firmware nella RAM.
Piccolo problema: dovresti essere abbastanza intelligente, dal punto di vista hardware, in modo che non si possa basta collegare un analizzatore logico tra il tuo MCU e il crypto IC e annusare i byte decrittografati.
Ci sono soluzioni alternative che offuscano le cose saltando selvaggiamente nella memoria mentre decifrano cose ecc. Il problema è che non cè niente segreto di questo, è solo un po più di lavoro per capire come si fa il salto dal codice macchina. (E se riesci a inserire un singolo pezzo di codice macchina su quel bus che fa in modo che lMCU esca tutta la sua RAM tramite un pin, anche il gioco è finito; non ti importa se sai dove quel pezzo di codice finisce nella RAM, lo troverai più tardi nel dump, è importante solo che venga eseguito a un certo punto.)
In altre parole, se pensi davvero al tuo firmware è questo commercialmente interessante (le persone lo sovrastimano selvaggiamente! Per cose che non sono principalmente firmware, come per qualsiasi dispositivo consumer e controllo industriale, di solito è difficile procurarsi tutte le parti e costruire il dispositivo stesso / simile più economico delloriginale e riscrivere completamente il firmware è spesso facile rispetto a quello), quindi lunica possibilità è integrare la conservazione dei segreti, larchiviazione crittografata e lesecuzione sicura (in modo che il dumping della RAM sia impossibile).
Ci sono microcontrollori che lo fanno. Di solito sono un po più costosi.Ma, come puoi immaginare, se ti trovi, ad esempio, in un ambiente di difesa in cui devi certificare che il firmware non può essere manomesso, beh, questa è la tua strada da percorrere.
Nintendo produce dispositivi in cui lincentivo finanziario a non consentire a nessuno di leggere il proprio firmware o addirittura di modificarlo è forte:
Lincapacità degli utenti di eseguire software che non era concesso in licenza da Nintendo sulle loro console è fondamentale per il loro modello di business. Pertanto, non essere in grado di aggirare il controllo delle firme del gioco è fondamentale, ed è per questo che un Nintendo Switch offre tutti i livelli di protezione. Come puoi immaginare, non è una garanzia: cerano semplicemente degli hobbisti (nemmeno persone con interessi criminali / commerciali!) Che hanno trovato un modo per aggirare questo problema.
Ma noterai una cosa: solo perché è difficile renderlo perfetto non significa che non ne valga la pena rendere più difficile clonare il tuo dispositivo. Nella mia umile esperienza, i clonatori tipicamente capitolano non appena avrai bisogno di capire come funziona un dispositivo per copiarlo, altrimenti sarebbero nella posizione di avere ingegneri che potrebbero fare il tuo lavoro, più o meno, e quegli ingegneri di solito lavorano nel tuo settore, non in qualche laboratorio di contraffazione. Un buon deterrente quindi è mettere il firmware crittografato in flash. Non è perfetto, ma nel momento in cui dovrebbero uscire dallanalizzatore logico e passare settimane a eseguire il reverse engineering del tuo protocollo di decrittazione in RAM, solo per ottenere qualcosa che potrebbero essere in grado di copiare, potrebbe essere sufficiente che considerino il rischio finanziario troppo alto e optino per alcuni altro.
Commenti
- " le persone lo sovrastimano selvaggiamente ", ma le persone sovrastimano altrettanto selvaggiamente il costo del reverse engineering.
- Grazie per lottima risposta, non possono votare a favore di non avere abbastanza reputazione. Sì, ' è praticamente impossibile renderlo sicuro al 100%, ma laggiunta di una misura di sicurezza molto semplice con un crypto chip da $ 0,3 potrebbe aumentare il costo del reverse engineering da circa $ 3 cifre a forse a 5 cifre, aumentando il tempo richiesto da pochi giorni a pochi mesi se la sicurezza è progettata in modo abbastanza intelligente. E potrebbe respingere gli hacker (a seconda del potenziale finanziario del prodotto) Penso che andrò avanti crittografando la " parte interessante " del firmware principale.
- ' ridimensionerò la stima fino a " aumentando il tempo da unora a forse qualche giorno " e il costo è sostanzialmente irrilevante in entrambi i casi. Il costo sarebbe " essenzialmente gratuito " per chiunque ' abbia mentito sugli strumenti elettronici in giro comunque, e anche se no, 200 € più un laptop ti danno un inizio ragionevole.
- Allora dovrei arrendermi e non usare alcuna protezione? 🙂
- @NotReallyaMaster che ' spetta a te; ' ho dedicato lintero ultimo paragrafo della mia risposta a questa domanda.