Come posso proteggere il software sul Pi per uso commerciale?

Vorrei utilizzare il Raspberry Pi in un prodotto commerciale, ma vorrei impedire la retroingegnerizzazione del software sul dispositivo. Il software in questione sarebbe scritto in Ruby. Suppongo che l'utente finale abbia accesso fisico alla scheda SD ed sia abbastanza intelligente da ottenere l'accesso root al Pi.

A mio avviso, le opzioni possono includere:

• Crittografa parte (o tutto) della scheda SD
• Offusca il codice Ruby o compilarlo in bytecode (JRuby o Rubinius)

La crittografia sarebbe la soluzione migliore, ma non riesco a pensare a un modo per decrittografare senza chiedere all'utente la chiave. L'offuscamento del codice è sicuramente possibile, ma meno sicuro nella mia mente.

È possibile crittografare una parte della scheda SD senza richiedere all'utente una chiave per decrittografarla? O c'è un modo migliore per assicurarsi che il codice sia accessibile solo sul dispositivo desiderato?

Naturalmente è possibile decrittografare file / container / etc crittografati. senza chiedere una password. È sufficiente archiviare la password (crittografata) sulla scheda SD e utilizzarla per decrittografare i dati. Ad esempio, una semplice openssldemo potrebbe essere:

openssl enc -a -e -salt -aes-256-cbc -pass pass:abc123 -in /tmp/plaintext.txt -out /tmp/ciphertext.enc

openssl enc -d -a -aes-256-cbc -pass pass:abc123 -in /tmp/ciphertext.enc

La crittografia verrebbe eseguita durante l'installazione del software sul Pi e la decrittografia verrebbe eseguita in fase di esecuzione, possibilmente nella RAM. Ad esempio, la password potrebbe essere una combinazione di un numero di sequenza pseudocasuale (noto a te) e il numero di serie del Pi specifico ottenuto da a cat /proc/cpuinfo. Quindi devi trovare una posizione opportunamente nascosta per memorizzare questo numero pseudocasuale che è a tutti gli effetti " la password " e quindi il punto debole dell'intero meccanismo di crittografia. Ad esempio, un settore di riserva sulla SD sarebbe la scelta tipica, ma puoi persino incorporarlo in uno dei tuoi eseguibili.

In ogni caso, l'opzione migliore è crittografare e compilare il software, per aggiungere diversi livelli di offuscamento al software.

Infine, se il tuo software necessita di una connessione Internet, puoi anche fare in modo che il Pi richieda la password ogni volta. Dovrai comunque nascondere la password all'interno della connessione, dovrai anche usarla httpse dovrai proteggerti dagli attacchi di risposta, usando l'ora corrente come saltper la crittografia.

Hai molte opzioni (economiche) per rendere sicuro il tuo software. Ma devi sapere che se il tuo software raggiunge una soglia di popolarità ben definita, sarà sicuramente crackato, anche se investi ingenti somme di denaro nella sua protezione.

In pratica, se il codice e le chiavi si trovano su un computer con scheda SD, saranno in grado di decompilarlo, saranno in grado di scoprire le chiavi e saranno in grado di estrarre i dati sensibili.

È come crittografare i film, un DVD deve includere tutte le informazioni necessarie per decrittografare il film in modo che possa essere visualizzato allo spettatore, quindi tutti i meccanismi di protezione dalla copia dei film sono condannati.

Il meglio che puoi fare è cambiare l'economia del reverse engineering del tuo prodotto.

Vale la pena crittografare e / o offuscare?

Ora abbiamo stabilito che non c'è modo di proteggerti completamente, le domande diventano

1. Quanto è probabile che accada?
2. Qual è il valore per qualcun altro del tuo algoritmo e dei tuoi dati?
3. Qual è il costo per loro di acquistare una licenza per utilizzare il tuo software?
4. Qual è il costo per loro di replicare algoritmo e dati?
5. Qual è il costo per il reverse engineering del tuo algoritmo e dei tuoi dati?
6. Qual è il costo per te per proteggere algoritmo e dati?

Se questi producono un imperativo economico significativo per proteggere il tuo algoritmo / dati, dovresti cercare di farlo. Ad esempio, se il valore del servizio e il costo per i clienti sono entrambi elevati, ma il costo dell'ingegnerizzazione inversa del codice è molto inferiore al costo di sviluppo da soli, le persone potrebbero tentarlo.

Quindi, questo porta alla tua domanda

• Come si proteggono l'algoritmo e i dati?

Offuscazione

L'opzione che suggerisci, offuscando il codice, rovina l'economia sopra - cerca di aumentare significativamente il costo per loro (5 sopra) senza aumentare molto il costo per te (6). Il problema è che, come con la crittografia DVD, è destinata a fallire e se c'è abbastanza differenziale tra 3, 4 e 5, alla fine qualcuno lo farà.

Un'altra opzione potrebbe essere una forma di steganografia , che consente di identificare chi ha decodificato il codice e ha iniziato a distribuirlo. Per esempio, se si dispone di 100 differenti valori float come parte dei dati, e un errore di 1 bit in LSB di ciascuno di questi valori non causerebbe un problema con l'applicazione, codificare un unico (a ciascun cliente) identificatore in quei bit . Il problema è che se qualcuno ha accesso a più copie dei dati dell'applicazione, sarebbe ovvio che differisce, rendendo più semplice l'identificazione del messaggio nascosto.

Protezione

L'unica opzione davvero sicura è quella di fornire una parte critica del tuo software come servizio , piuttosto che includerlo nella tua applicazione.

Concettualmente, la tua applicazione raccoglierebbe tutti i dati necessari per eseguire l'algoritmo, impacchettandolo come richiesta a un server (controllato da te) nel cloud , il tuo servizio calcolerebbe quindi i risultati e li rimanderebbe al client, che lo mostrerebbe.

Ciò mantiene tutti i tuoi dati e algoritmi riservati e riservati all'interno di un dominio che controlli completamente e rimuove qualsiasi possibilità di estrazione di un client.

L'ovvio aspetto negativo è che i clienti sono legati alla tua prestazione di servizi, sono in balia dei tuoi server e della loro connessione Internet. Tra i lati positivi, sono sempre aggiornati con le correzioni di bug. Sfortunatamente molte persone si oppongono a SaaS proprio per questi motivi.

Questo sarebbe un grande passo da fare, e potrebbe avere un enorme costo 6 sopra, ma è l'unico modo che posso vedere per mantenere il tuo algoritmo e i tuoi dati completamente sicuri .

Di recente ho inventato una soluzione molto elegante a questo problema irrisolvibile. È stato ispirato da questo fumetto di xkcd:

Quindi la soluzione si chiama super colla . Se una scheda SD supercolla sull'IP sarà quasi impossibile estrarre la scheda senza danneggiarla.

Puoi anche utilizzare un disco SSD esterno, crittografato con una password memorizzata su SD e sentirti al sicuro!

La compilazione in bytecode sarebbe il miglior repellente. Per quanto riguarda la crittografia, il software potrebbe essere archiviato nel volume TrueCrypt, ma solo se l'utente non avesse ottenuto l'accesso root; non è possibile archiviare in modo sicuro la password poiché la memoria / il disco possono essere scaricati in qualsiasi momento per l'ispezione. Anche l'aiuto di dispositivi sicuri (smart card) non farebbe molto, se il software viene eseguito in cui l'utente ha una pletora di utility Linux. Per quanto ne so, l'avvio sicuro non è un'opzione su R-Pi che impedisce agli utenti di armeggiare all'interno del sistema operativo.

Se vuoi creare una vera applicazione commerciale, allora il Pi, com'è nella sua forma per l'utente finale, non ti va bene!

Dovrai progettare il tuo PCB, ad esempio utilizzare il processore che si trova sul Pi e incorporare una memoria flash sul PCB.

1. Scrivi un firmware di proprietà per BCM che ha generato un unico codice di accesso basato su un algoritmo top secret che può essere utilizzato solo entro i prossimi 10 secondi.
2. Compilare il proprio kernel con il proprio software proprietario e abilitare alcune funzionalità di Linux che consentono di montare root da un file crittografato sul flash, che contiene un'altra partizione crittografata con il proprio software (doppia protezione)
3. Il tuo firmware BCM genererà una chiave di autenticazione top secret una volta disattivata basata su alcuni algoritmi intelligenti o chiavi pubbliche e lo passerà al tuo linux kernal personalizzato, che caricherà la partizione root crittografata e farà alcune cose crittografiche durante l'avvio per caricare l'unità software crittografata all'interno dell'immagine crittografata.

SUGGERIMENTI

• Le buone chiavi di autenticazione non sono lunghe 8-16 caratteri. È importante fornire chiavi di autenticazione lunghe 256/512 byte utilizzando più simboli di sistema (HEX) e meno caratteri (ASCII)
• Non utilizzare AES, TKIP in quanto è facilmente crackabile
• Ad oggi, la crittografia Whirlpool è tra le più complicate da decifrare usando 256/512 chiavi
• Anche se un hacker può rimuovere l'unità flash o scaricare il contenuto. il tuo software è crittografato due volte.
• Se intercettano la chiave di autenticazione, sarà molto difficile uscire dal firmware (perché il BCM può impedire i dump del firmware)
• Alcune ROM flash intelligenti hanno anche una funzione per impedire dump della memoria completa.
• Se stai progettando un PCB, implementerai (come Dell e Apple) un chip di sicurezza che fornisce tutti i dati e le chiavi di crittografia e previene i tentativi di bruteforce. Alcuni Dell hanno un autodistruzione per uso militare. Se la password del BIOS viene inserita in modo errato per 2 volte, questo cancella le unità con bombe a dispersione. È possibile implementare lo stesso se si rilevano manipolazioni della chiave di autenticazione.

Fine del giorno. Raspberry Pi è destinato a scopi didattici per consentire ai bambini di imparare a usare Linux e scrivere alcuni programmi.

Non è adatto per un uso commerciale di alto profilo. Devi creare il tuo dispositivo e creare i tuoi sistemi di protezione. Perché se solo tu e nessun altro sapete come proteggere le vostre informazioni di proprietà, allora le probabilità che qualcuno le hackeri usando un exploit noto o brutale è dello 0,001%

ALTERNATIVE

• Scrivi il tuo software in modo che possa essere compilato e distribuito al sistema di destinazione in un formato binario. Esempio EXE per Windows che funziona su .NET, JAR per Java o (Non sei sicuro in Linux, C ++?)
• Ricorda, migliore è la sicurezza che desideri: più soldi dovrai spendere per questo. Non ci sono eccezioni

Una delle soluzioni è utilizzare l'indirizzo MAC di RaspberryPi, che è quasi unico per un determinato Pi. Verifica questo indirizzo all'interno del tuo codice e fornisci la versione compilata. Ciò renderà difficile il reverse engineering.

Per le persone che copiano ciecamente la scheda SD su una nuova, non funzionerà per loro su un altro Pi. Ciò eliminerà la stragrande maggioranza delle persone che rubano il tuo software. Altri che sono abbastanza intelligenti da rompere questo possono essere abbastanza intelligenti da rifare il software, i loro non sono numerosi e non credo che danneggeranno le tue vendite.

È possibile utilizzare una soluzione basata sulle spalle: Software Serial Protection per Raspberry Pi

Perché non aggiungere un flash basato su SPI alla scheda del gestore telefonico e memorizzare il codice su di esso? Sto considerando questa opzione per il mio prodotto. Nel caso in cui la SD venga corrotta, voglio che l'utente finale sia in grado di scriverne uno nuovo, che includa una raspbian personalizzata, e il codice per montare il flash SPI ed eseguire l'eseguibile.

Un'altra opzione è la memorizzazione di una chiave di crittografia nel RTC. La maggior parte dei chip RTC ha un po 'di spazio di archiviazione e potrebbero essere preprogrammati con la chiave che consente di sbloccare e montare l'eseguibile da SD o da flash SPI.

Credo che tutte le CPU utilizzate nella gamma di Raspberry Pi supportino un avvio sicuro. Credo che occorra 12 volt per eseguire il reflash dei 4,8,16,32 o 64 K di flash interno o EEPROM che il pi stesso non ha. Dal loro, puoi configurare Trustzone con il tuo codice in modo da non poter vedere tutte le cose buone. Comprendo anche che entrambe le forme di RAM statica sono stabili solo per un determinato numero di riscritture. Il mio primo passo sarebbe quello di avere una CPU di riserva e provare a eseguire il reflashing di questa memoria di avvio sicura per alcune ore o giorni. Alla fine, tutti i bit vengono riparati in modo che nessun altro possa modificare il codice e in base al prodotto reale, è possibile richiedere periodicamente un'identificazione a 2 fattori (come le banche) in modo che il prodotto sputi un codice e il codice di riattivazione venga inviato a l'indirizzo e-mail. Se modichi un po 'il pi, Credo che ARM abbia anche un CPUID, quindi ci sono un certo numero di livelli di sicurezza che puoi scegliere. Voglio dire, potresti anche offrire un SMS a un numero specifico. Molti modi.