Dopo un po 'di tempo con Raspberry Pi 2 Model B v1.1., Ho le seguenti preoccupazioni?

1. So che è focalizzato a migliorare i settori educativi vulnerabili, ma è possibile vendere un prodotto, basato sul RPi ?. Per fare soldi con esso ?. Diventa miliardario con esso ?.
2. Come dovrei proteggere uno sviluppo, diciamo, non voglio che qualcuno prenda la mia scheda SD RPi, la duplichi e abbia le proprie repliche ? La mia alternativa attuale è riempire la porta della SDCard con supercolla :). Un'altra scelta potrebbe fare in modo che RPi esegua il ping di un server delle licenze online, il che ovviamente richiederebbe una connessione WiFi . O un ID HASH hardware (questa dovrebbe essere una risposta migliore immagino ...)
3. Ho verificato che ci sono anche meccanismi per ripristinare l'installazione anche se non si dispone del root, montando la scheda SD. Ancora una volta, la mia migliore soluzione è l'approccio superglue ....

Grazie in anticipo.

Se sei davvero preoccupato di proteggere la tua proprietà intellettuale, allora puoi combinare la tua applicazione basata su Rapberry Pi con una chiave hardware basata su un micro controller esterno personalizzato (MCU come AVR, PIC, 8051 ...) (collegato a Pi tramite USB, RXTX, I2C, SPI, 1wire ...). Ad esempio, l'applicazione laterale Pi genera un numero casuale che viene inviato a MCU, decodificato e rispedito come chiave di sblocco per decrittografare qualcosa di importante. Inoltre, hai alcune importanti funzioni eseguite direttamente in MCU (devi solo passare i parametri e ottenere il risultato dall'MCU). Puoi immaginare come ciò aumenterebbe la difficoltà di cracking per un hacker in ordine di grandezza, poiché la sua conoscenza dovrebbe essere molto più ampia del solito. Non esiste una protezione perfetta, ma se vuoi davvero renderla una sfida, questa potrebbe essere una strada da percorrere.

1. Penso che sia stata l'idea con il modulo di calcolo per tutto il tempo. Non dovrebbe essere un problema generare profitti.

2. / 4. L'opzione supercolla è probabilmente un buon compromesso. Alla fine non puoi sconfiggere un attaccante con accesso fisico al dispositivo. Dai un'occhiata alle console di gioco che probabilmente hanno investito milioni in infrastrutture DRM e alla fine cadono tutte. In uno spirito diverso, potresti anche abbracciare l'apertura e vendere una versione di sviluppo del tuo prodotto e includere un qualche tipo di SDK. Il feedback che ricevi da un gruppo di utenti focalizzato sulla tecnica potrebbe essere prezioso e funzionare nel tuo interesse.

Mentre questa pratica sta sicuramente perdendo la copertura, rimarrai stupito dalla quantità di connettori USB che sono stati incollati su macchine desktop in ambienti aziendali. E sto parlando di grandi multinazionali qui.

Ma ora in tema ...

Per i progetti commerciali in cui la protezione IP è un fattore importante, il Pi è ottimo per la prototipazione precoce / la prova del concetto nella migliore delle ipotesi. Anche se la protezione non sarebbe un problema, le implementazioni del Pi su larga scala non sono la soluzione migliore per IMHO - per una serie di motivi che ho descritto in una discussione precedente su questo forum.

Non esiste un sistema sicuro contro il reverse engineering / hacking / riproduzione. Qualsiasi sistema è sfruttabile. Ogni sistema ha comunque un punteggio di penetrazione. Con il suo approccio aperto e la scheda SD esterna, il Pi ne ha uno molto basso. Una scheda hardware progettata su misura approvata dai militari con SoC personalizzato, componenti a sandwich e PCB multistrato in combinazione con un bootloader personalizzato, la crittografia hardware avrà un punteggio più alto.

Inoltre, c'è il fattore di distribuzione. Più ampio è il tuo mercato, più interessante sarà per le persone irrompere e rubare la tua tecnologia.

Se l'hardware è il tuo pezzo di resistenza nell'intero setup e proteggere la tua tecnologia è un fattore importante, non credo che Pi sia il prodotto che fa per te. Se il tuo hardware è un facilitatore per la vendita di servizi, forse la protezione della tecnologia dovrebbe essere fatta sul lato server piuttosto che sul lato client.

Usiamo il Pi per vendere tali servizi. Il nostro software sul Pi ha un livello di protezione elevato, stiamo usando un'applicazione C compilata, bloccata su MAC e / o numero seriale CPU. Ma alla fine, senza il nostro lato server, anche il codice sorgente è praticamente inutile.

È possibile utilizzare un piggy-back all'interno di lampone con una chiave di crittografia. Ci sono un paio di dispositivi commerciali sul mercato. Ho usato questo software Serial Protection per Raspberry Pi , che funziona molto bene.

Rendilo open-source

Seriamente non provare a proteggerlo dalla copia. Rendilo open-source. Se possibile, lascia che altri si uniscano al tuo progetto.

Quindi addebitare i servizi. Puoi guadagnare soldi se lo fai nel modo giusto.

Red-had lo fa così e alcune altre società. Stanno tutti bene e stanno crescendo.

Alcuni miei centesimi:

1. Non creare mai una soluzione attorno agli script che possono essere letti direttamente.
2. Funzionalità di suddivisione in termini di più software / processi e hardware.
3. Aggiungi una dipendenza "funzionale" all'hardware letto.
4. Aggiungi il lettore di smart card e vendi smart card "abilitante" con il tuo prodotto.
5. Avere un server delle licenze
6. Avere un contatore di utilizzo in EEPROM !!! E ci dovrebbe essere un modo per "ricaricare" online .. ;-)

...

Come protezione entry-level, è presente un ID scheda SD univoco al di sotto del /sys/block/mmcblk0/device/quale non viene clonato dal tipico software di clonazione delle immagini del disco. Questo ha il vantaggio di non richiedere un dispositivo separato per contenere l'ID univoco e funziona abbastanza bene come secondo livello di protezione dopo la supercolla. Almeno fermerà le persone in grado di clonare semplicemente la scheda SD.

Un altro consiglio per quanto riguarda la protezione tramite ID è di evitare di utilizzare un semplice controllo, ad es

if(readID() != 0xDEADBEEF) exit();

Semplici controlli di questo tipo sono facili da scoprire (cercando l'ID noto o monitorando le chiamate a exit()) e rimuovendoli. Un approccio molto migliore consiste nel coinvolgere l'ID come costante nei calcoli. Cioè, invece che da i++qualche parte nel tuo codice scriverai

i = i + readID() - 0xDEADBEEF + 1;

Questo sarà molto più difficile da scoprire, poiché l'ID esatto non apparirà nel tuo codice verbatim ( 0xDEADBEEF + 1 == 0xDEADBEF0) e anche ispezionare tutte le chiamate exit()non rivelerà la posizione del tuo codice di protezione. Al contrario, il codice si bloccherà semplicemente su un sistema con l'ID errato e l'utente malintenzionato dovrà eseguire il debug della logica dell'applicazione per comprendere e risolvere il problema.

Usando un componente esterno, intendevo che il componente di sicurezza avrebbe risolto quel problema. Se pensi davvero che la tua idea sia fantastica e che valga la pena di aggiungere un costo aggiuntivo, ti suggerirei di utilizzare un MCU / CPU professionale per farlo. Come la serie Broadcom BCM58101, non è davvero conveniente e non è amichevole per un nuovo utente, ma un elevato livello di sicurezza può anche proteggere la tua idea / progettazione.