La protezione secondo Microchip
Quando si dice che fare sicurezza è un lavoro arduo, non è tanto per dire...
Risulta infatti possibile estrarre tutto il codice da un (beh, in realtà è necessario usarne due...) PIC18F senza bisogno di ricorrere ad attacchi invasivi!
E non è neanche difficile.
La particolarità che viene sfruttata in questo attacco è che il boot block (i primi 512 byte di codice) può essere sovrascritto indipendentemente dagli altri blocchi.
Questo non vi fa già squillare un campanello d'allarme simile alla "Gertrude" di Don Camillo? No? Malissimo!
In pratica potete semplicemente sostituire sul primo PIC il boot loader con un "memory dumper" che permetta la lettura di tutto il resto del codice e della EEPROM. Fatto questo, avrete in mano tutto il codice tranne il boot loader.
Quindi, sul secondo PIC andrete a riprogrammare tutto tranne il bootloader con dei NOP, lasciando alla fine della memoria il dumper: quando il bootloader cederà il controllo a quello che crede essere il suo sw, in realtà "centrerà" un NOP, e quindi l'esecuzione potrà procedere fino al dumper, il quale farà il suo lavoro e vi fornirà il codice del bootloader!
Fine dei giochi: bootloader + resto del codice + EEPROM ed il PIC è copiato!
L'unico metodo per una protezione (molto parziale, e solo per i dati in EEPROM) è di usare una split-key diversa per ogni dispositivo, contenuta parzialmente nel bootsector e parzialmente nel resto del codice, un po' in ogni blocco. Meglio se si mettono 8 byte random ogni blocco e 16 o 32 nel boot block, su cui calcolare un hash (si possono includere nell'hash anche i fusibili ed il device-ID... ma meglio evitare di usare tutto il codice per non facilitare attacchi intrusivi con probe dei bus interni) per ottenere la chiave con cui criptare i dati in EEPROM. In questo modo, un attaccante non avrà modo di leggere i dati poiché non sarà in grado di avere la chiave completa, ma gli mancheranno sempre almeno 64 bit.
In ogni caso, per chi ancora non se ne fosse reso conto, i PIC non sono processori sicuri. Per lo meno in applicazioni "sensibili". Il loro target di protezione è la difesa dall'attaccante occasionale, e fin lì ci possono arrivare. Per altre applicazioni vanno difesi con altri metodi.
Commenti
ma allora il fusibile PROTECT
ma allora il fusibile PROTECT che mette a disposizione CCS non funziona?
Si e no
Nel senso che fa quel che dice. No more, no less.
Se il tuo progetto è un esemplare singolo, allora è abbastanza al sicuro -- almeno da attacchi così elementari (ma continua a leggere).
Se invece sono vari esemplari, meglio ricorrere a protezioni un pelino più evolute. L'importante è conoscere più attacchi possibile per sapere come combatterli.
Poi nessun chip è inviolabile (tranne, forse un wafer di 3 chip, coi due esterni che hanno solo funzioni di interfaccia e schermatura per la logica che risiede in RAM in quello centrale): perfino un modulo TPM è stato decappato ed ha "ceduto le chiavi", come ho riportato su openalarm.info (dagli stessi link, consiglio caldamente la lettura della pagina di Sergei Skorobogatov...).
Moltissimi PIC, una volta decappati, espongono il fusibile di protezione in modo abbastanza evidente: chi ha un centomila euro da buttare (e sto largo! probabilmente ultimamente il costo dell'attrezzatura è molto calato!), può riprogrammare solo il fusibile di protezione e leggersi comodamente il codice. In altri, addirittura (IIRC il PIC 16C84) è sufficiente un glitch al momento opportuno durante la programmazione per evitare la cancellazione di tutto tranne che dei fusibili.
Dipende, come sempre, da quanto ritieni che un attaccante sia disposto a spendere per copiare il tuo codice. E non sempre la soluzione è solo tecnica. In OpenAlarm, per esempio, se un sensore viene rimosso dal sistema per un tempo sufficiente a far sospettare che sia stato copiato, la centralina non lo riaccetta senza che venga nuovamente inizializzato con una chiave fresca. E visto che la chiave sarà l'unica cosa segreta (progetto opensource), tentare la copia sarà assolutamente inutile.