Quanto è facile decifrare la seguente protezione dalla copia? [chiuso]

Sto cercando di proteggere dalla copia un po 'di lavoro, che è una scheda SD avviabile che avvia un kernel Linux su un dispositivo ARM (Raspberry Pi). Sto usando questo approccio:

1. L'approccio utilizza un initrd per montare un filesystem di root crittografato.
2. Initrd genera la password del filesystem in base al CID della scheda SD. (viene utilizzata una funzione hash, non ha ancora deciso su md5 o sha1). Initrd proverà a montare il filesystem usando quella password generata.
3. Ora ecco la parte più interessante / sospetta: lo stesso initrd è crittografato usando una funzione C personalizzata, praticamente ogni byte è XOR usando un generatore pseudo casuale personalizzato. Il kernel viene modificato per avere la stessa funzione di crittografia, che funziona come decryptor.
4. Il sistema stesso è ridotto quindi non è possibile utilizzare una tastiera o una memoria esterna. Una singola app viene eseguita a schermo intero.

Quindi dopo che il bootloader carica kernel e initrd, il kernel decodifica initrd ed esegue il suo script init, che genererà la password e monterà il filesystem di root.

La mia domanda è: quanto sarebbe facile interrompere questa configurazione (per decrittografare il filesystem di root e farlo partire da qualsiasi scheda SD)? Quali sono le parti più deboli? Quanto è facile decompilare il kernel e trovare quelle funzioni di crittografia personalizzate?

EDIT: Ecco alcune correzioni in modo da non perdere tempo con le cose ovvie:

1. Il dispositivo root verrà crittografato con LUKS (aes256) e la chiave verrà generata da alcune funzioni HMAC utilizzando il CID della scheda SD e un po 'di sale.
2. L'algoritmo pseudo casuale per la crittografia di initramfs sarà in realtà RC4, solo la chiave verrà generata utilizzando una funzione personalizzata, perché se memorizzo semplicemente la chiave in un array di byte, è molto semplice recuperarla (sì, questa è sicurezza attraverso l'oscurità ma non sembra esserci altro modo).
3. Capisco che se si utilizza un emulatore della scheda SD qualcuno può avviare una copia di questo sistema, ma per me va bene, perché è piuttosto difficile e non tutti possono farlo. (Inoltre, nessuno vorrà gestire gli emulatori)

Quanto sarebbe facile interrompere questa configurazione (per decrittografare il filesystem di root e farlo partire da qualsiasi scheda SD)?

Quanto sia difficile "interrompere" la tua configurazione dipende dal numero di bit di entropia in qualunque metodo stai usando per firmare / crittografare il filesystem stesso (poiché questo determina il numero totale di combinazioni uniche che possono essere usate per la forza bruta la password).

Quali sono le parti più deboli?

Senza dubbio, utilizzando un CID predefinito come password, nonché una funzione di generazione di numeri pseudo-casuale personalizzata.

Il CID di una scheda SD dovrebbe essere di sola lettura, ma al giorno d'oggi non è raro trovare dispositivi di memoria flash non conformi. Alcune persone hanno persino dimostrato la possibilità di sovrascrivere il CID con alcune schede SD. Ciò renderebbe più semplice forzare la password, soprattutto se si sta solo emulando una scheda SD dopo aver clonato la propria (qualcos'altro che si potrebbe prendere in considerazione).

Infine, l'utilizzo di qualsiasi tipo di generatore di numeri pseudo-casuali ha già alcuni difetti intrinseci, proprio perché non è casuale - c'è una ragione per cui si chiama pseudo-casuale . Potrebbe essere meglio usare un bootloader crittografato pre-creato (come TrueCrypt o LUKS, che funzionano entrambi su Raspberry Pi) ed evitare di dover apportare modifiche manuali al kernel.

Quanto è facile decompilare il kernel e trovare quelle funzioni di crittografia personalizzate?

È molto difficile decompilare qualsiasi cosa. Al contrario, il disassemblaggio di un'applicazione compilata è spesso banale e ci sono molti strumenti che possono essere utilizzati per aiutare il reverse engineering assembly in un altro linguaggio di livello superiore. Se un attaccante ha accesso anche a un kernel compilato, analizzare qualcosa come un generatore di numeri pseudo-casuale è probabilmente banale a meno che il codice non sia offuscato di proposito.

TL, DR : non reinventare la ruota quando si tratta di crittografia e sicurezza, attenersi al provato e vero. Esistono diverse opzioni di crittografia dell'intero disco che sono già disponibili e hanno dimostrato di funzionare perfettamente su Raspberry Pi. Eviterei di usare il CID della scheda SD come una sorta di "password" - anche se non può essere modificato, ci sono modi per falsificare questo valore.

La protezione dalla copia è già inclusa nelle specifiche della scheda SD come CPRM .

Qualcuno esperto non avrebbe molti problemi a risolverlo. Sarebbe relativamente facile avviare la scheda SD sotto un emulatore e quindi leggere le chiavi dalla RAM. Quindi pubblicano una versione senza protezione dalla copia nella Pirate Bay (ecc.), E basta.

In alternativa, utilizzare l'emulatore per iniettare il codice shell nel sistema emulato in esecuzione. Quindi utilizzare il sistema in esecuzione per copiare i rootfs decodificati (o leggere le chiavi usando dmsetup table --showkeys, ecc.)

Una rapida ricerca rivela l'esistenza degli emulatori di Raspberry Pi , quindi parte del lavoro è già stata eseguita.

Hai un altro problema, in particolare questo:

Il kernel viene modificato per avere la stessa funzione di crittografia, che funziona come decryptor.

Chiunque lo distribuisca ha diritto al codice sorgente del kernel, secondo i termini della GPL. Quindi non dovresti smontarlo, potresti semplicemente usare diffper trovare la funzione extra.

(Non che trovarlo attraverso il disassemblaggio sarebbe così difficile, come puoi ad esempio controllare rispetto a un kernel stock)

Non conosco completamente il codice di avvio di Raspberry Pi, ma se riesci a eseguire il reflash del bootloader con una chiave crittografica incorporata (che viene quindi passata al kernel), almeno non si troverebbe sulla scheda SD, quindi " sventare un tentativo di farlo avviare in un emulatore.