¿Qué tan fácil es descifrar la siguiente protección de copia? [cerrado]

Estoy tratando de proteger contra copia algún trabajo, que es una tarjeta SD de arranque que arranca un kernel de Linux en un dispositivo ARM (Raspberry Pi). Estoy usando este enfoque:

1. El enfoque utiliza un initrd para montar un sistema de archivos raíz cifrado.
2. El initrd genera la contraseña del sistema de archivos de acuerdo con el CID de la tarjeta SD. (se utiliza una función hash, aún no se decidió sobre md5 o sha1). Initrd intentará montar el sistema de archivos usando esa contraseña generada.
3. Ahora aquí está la parte más interesante / sospechosa: el initrd en sí está encriptado usando una función C personalizada, básicamente cada byte es XOR usando un generador pseudoaleatorio hecho a medida. Kernel se modifica para tener la misma función de cifrado, que funciona como descifrador.
4. El sistema en sí está reducido, por lo que no hay forma de usar un teclado o almacenamiento externo. Una sola aplicación se ejecuta a pantalla completa.

Entonces, después de que el gestor de arranque carga el núcleo y el initrd, el núcleo descifra el initrd y ejecuta su script de inicio, que generará la contraseña y montará el sistema de archivos raíz.

Mi pregunta es: ¿Qué tan fácil sería romper esta configuración (descifrar el sistema de archivos raíz y hacer que arranque desde cualquier tarjeta SD)? ¿Cuáles son las partes más débiles? ¿Qué tan fácil es descompilar el núcleo y encontrar esas funciones de cifrado personalizadas?

EDITAR: Aquí hay algunas correcciones para que no pierdas el tiempo con las cosas obvias:

1. El dispositivo raíz se cifrará con LUKS (aes256) y la clave será generada por alguna función HMAC utilizando el CID de la tarjeta SD y algo de sal.
2. El algoritmo pseudoaleatorio para el cifrado de initramfs será, de hecho, RC4, solo la clave se generará utilizando alguna función personalizada, porque si solo almaceno la clave en una matriz de bytes, es muy sencillo recuperarla (sí, esto es seguridad a través de la oscuridad pero parece que no hay otra manera).
3. Entiendo que si usa un emulador de tarjeta SD, alguien puede hacer que se inicie una copia de este sistema, pero esto está bien para mí, porque es bastante difícil y nadie puede hacer esto (tampoco nadie querrá tratar con emuladores)

¿Qué tan fácil sería romper esta configuración (para descifrar el sistema de archivos raíz y hacer que arranque desde cualquier tarjeta SD)?

Lo difícil que es "romper" su configuración depende de la cantidad de bits de entropía en cualquier método que esté usando para firmar / cifrar el sistema de archivos en sí (ya que esto determina la cantidad total de combinaciones únicas que se pueden usar para la fuerza bruta la contraseña).

¿Cuáles son las partes más débiles?

Sin duda, usar un CID predefinido como contraseña, así como también usar una función personalizada de generación de números pseudoaleatorios.

Se supone que el CID de una tarjeta SD es de solo lectura, pero no es raro encontrar dispositivos de memoria flash no compatibles en la actualidad. Algunas personas incluso han demostrado la capacidad de sobrescribir el CID con ciertas tarjetas SD. Esto facilitaría la fuerza bruta de la contraseña, especialmente si uno simplemente está emulando una tarjeta SD después de clonar la suya (que es algo más que puede considerar).

Finalmente, el uso de cualquier tipo de generador de números pseudoaleatorio ya tiene algunos defectos intrínsecos, precisamente porque no es aleatorio ; hay una razón por la que se llama pseudoaleatorio . Puede ser mejor usar un gestor de arranque cifrado prefabricado (como TrueCrypt o LUKS, que funcionan en la Raspberry Pi) y evitar tener que realizar modificaciones manuales en el núcleo.

¿Qué tan fácil es descompilar el núcleo y encontrar esas funciones de cifrado personalizadas?

Es muy difícil descompilar algo. Por el contrario, el desmontaje de una aplicación compilada es a menudo trivial, y hay muchas herramientas que pueden usarse para ayudar con el ensamblaje de ingeniería inversa a otro lenguaje de nivel superior. Si un atacante tiene acceso incluso a un núcleo compilado, el análisis de algo como un generador de números pseudoaleatorio es probablemente trivial a menos que el código se ofusque a propósito.

TL, DR : No reinventes la rueda cuando se trata de cifrado y seguridad, quédate con lo probado y verdadero. Hay varias opciones de cifrado de disco completo que ya están disponibles y se ha demostrado que funcionan bien en Raspberry Pi. Evitaría usar el CID de la tarjeta SD como una especie de "contraseña", incluso si no se puede cambiar, hay formas de falsificar este valor.

La protección contra copia ya está incluida en la especificación de la tarjeta SD como CPRM .

Alguien experto no tendría muchos problemas para resolver esto. Sería relativamente fácil arrancar la tarjeta SD con un emulador y luego simplemente leer las claves de la RAM. Luego publican una versión sin protección de copia en Pirate Bay (etc.), y eso es todo.

Alternativamente, use el emulador para inyectar shellcode en el sistema emulado en ejecución. Luego use el sistema en ejecución para copiar los rootfs descifrados (o lea las claves usando dmsetup table --showkeys, etc.)

Una búsqueda rápida revela la existencia de emuladores de Raspberry Pi , por lo que parte del trabajo ya está hecho.

Tienes otro problema, en particular este:

Kernel se modifica para tener la misma función de cifrado, que funciona como descifrador.

Cualquier persona a quien distribuya esto tiene derecho al código fuente del núcleo, bajo los términos de la GPL. Por lo tanto, no necesitaría desmontarlo, simplemente podría usarlo diffpara encontrar la función adicional.

(No es que encontrarlo a través del desensamblaje sea tan difícil, como puede, por ejemplo, verificar frente a un núcleo de stock)

No estoy completamente familiarizado con el código de arranque de Raspberry Pi, pero si puede volver a cargar el gestor de arranque con una clave criptográfica incrustada (que luego se pasa al kernel), al menos no estaría en la tarjeta SD, así que ' d frustrar un intento de hacer que arranque en un emulador.