Est-il facile de casser la protection contre la copie suivante? [fermé]

J'essaie de protéger certains travaux contre la copie, qui est une carte SD amorçable démarrant un noyau Linux sur un périphérique ARM (Raspberry Pi). J'utilise cette approche:

1. L'approche utilise un initrd pour monter un système de fichiers racine chiffré.
2. L'initrd génère le mot de passe des systèmes de fichiers en fonction du CID de la carte SD. (une fonction de hachage est utilisée, n'a pas encore décidé sur md5 ou sha1). Initrd essaiera de monter le système de fichiers en utilisant ce mot de passe généré.
3. Maintenant, voici la partie la plus intéressante / suspecte: l'initrd lui-même est chiffré à l'aide d'une fonction C personnalisée, fondamentalement chaque octet est XOR à l'aide d'un générateur pseudo aléatoire personnalisé. Le noyau est modifié pour avoir la même fonction de cryptage, qui fonctionne comme décrypteur.
4. Le système lui-même est dépouillé, il n'y a donc aucun moyen d'utiliser un clavier ou un stockage externe. Une seule application fonctionne en plein écran.

Ainsi, après que le chargeur de démarrage charge le noyau et initrd, le noyau déchiffre l'initrd et exécute son script init, qui générera le mot de passe et montera le système de fichiers racine.

Ma question est: comment serait-il facile de casser cette configuration (pour décrypter le système de fichiers racine et le faire démarrer à partir de n'importe quelle carte SD)? Quelles sont les parties les plus faibles? Est-il facile de décompiler le noyau et de trouver ces fonctions de chiffrement personnalisées?

EDIT: Voici quelques corrections pour ne pas perdre de temps avec les choses évidentes:

1. Le périphérique racine sera crypté avec LUKS (aes256) et la clé sera générée par une fonction HMAC à l'aide du CID de la carte SD et du sel.
2. L'algorithme pseudo aléatoire pour le cryptage initramfs sera en fait RC4, juste la clé sera générée en utilisant une fonction personnalisée, car si je stocke simplement la clé dans un tableau d'octets, il est très simple de la récupérer (ouais c'est la sécurité par l'obscurité mais il ne semble pas y avoir d'autre moyen).
3. Je comprends que si vous utilisez un émulateur de carte SD, quelqu'un peut faire une copie de ce système, mais c'est OK avec moi, car c'est assez difficile et personne ne peut le faire (également personne ne voudra traiter avec des émulateurs)

Comment serait-il facile de casser cette configuration (pour décrypter le système de fichiers racine et le faire démarrer à partir de n'importe quelle carte SD)?

La difficulté de "casser" votre configuration dépend du nombre de bits d'entropie dans la méthode que vous utilisez pour signer / crypter le système de fichiers lui-même (car cela détermine le nombre total de combinaisons uniques qui peuvent être utilisées pour forcer la force brute). le mot de passe).

Quelles sont les parties les plus faibles?

Sans aucun doute, l'utilisation d'un CID prédéfini comme mot de passe, ainsi que l'utilisation d'une fonction de génération de nombres pseudo-aléatoire personnalisée.

Le CID d'une carte SD est uniquement censé être en lecture seule, mais il n'est pas rare de trouver des dispositifs de mémoire flash non conformes à notre époque. Certaines personnes ont même démontré la possibilité d' écraser le CID avec certaines cartes SD. Cela faciliterait la force brute du mot de passe, surtout si l'on émule simplement une carte SD après avoir cloné la vôtre (ce que vous voudrez peut-être envisager).

Enfin, l'utilisation de tout type de générateur de nombres pseudo-aléatoires présente déjà des défauts intrinsèques, précisément parce qu'il n'est pas aléatoire - il y a une raison pour laquelle il est appelé pseudo-aléatoire . Il pourrait être préférable d'utiliser un chargeur de démarrage chiffré prédéfini (comme TrueCrypt ou LUKS, qui fonctionnent tous les deux sur le Raspberry Pi) et d'éviter d'avoir à apporter des modifications manuelles au noyau.

Est-il facile de décompiler le noyau et de trouver ces fonctions de chiffrement personnalisées?

Il est très difficile de décompiler quoi que ce soit. Inversement, le désassemblage d'une application compilée est souvent trivial, et il existe de nombreux outils qui peuvent être utilisés pour aider à l'assemblage de l'ingénierie inverse dans un autre langage de niveau supérieur. Si un attaquant a accès même à un noyau compilé, analyser quelque chose comme un générateur de nombres pseudo-aléatoires est probablement trivial à moins que le code ne soit obscurci exprès.

TL, DR : Ne réinventez pas la roue en matière de cryptage et de sécurité, restez fidèle à ce qui a fait ses preuves. Il existe plusieurs options de chiffrement du disque complet qui sont déjà disponibles et qui se sont avérées fonctionner correctement sur le Raspberry Pi. J'éviterais d'utiliser le CID de la carte SD comme une sorte de "mot de passe" - même s'il ne peut pas être modifié, il existe des moyens d'usurper cette valeur.

La protection contre la copie est déjà incluse dans la spécification de la carte SD en tant que CPRM .

Une personne qualifiée n'aurait pas beaucoup de mal à résoudre ce problème. Il serait relativement facile de démarrer la carte SD sous un émulateur, puis de simplement lire les clés de la RAM. Ensuite, ils publient une version sans protection contre la copie sur Pirate Bay (etc.), et c'est tout.

Vous pouvez également utiliser l'émulateur pour injecter le shellcode dans le système émulé en cours d'exécution. Ensuite, utilisez le système en cours d'exécution pour copier les rootfs décryptés (ou lire les clés à l'aide dmsetup table --showkeys, etc.)

Une recherche rapide révèle l'existence d' émulateurs Raspberry Pi , donc une partie du travail a déjà été effectuée.

Vous avez un autre problème, en particulier celui-ci:

Le noyau est modifié pour avoir la même fonction de cryptage, qui fonctionne comme décrypteur.

Toute personne à qui vous la distribuez a droit au code source du noyau, selon les termes de la GPL. Vous n'avez donc pas besoin de le démonter, vous pouvez simplement l'utiliser diffpour trouver la fonction supplémentaire.

(Ce n'est pas que le trouver par le démontage serait si difficile, comme vous pouvez par exemple le vérifier par rapport à un noyau de stock)

Je ne suis pas complètement familier avec le code de démarrage du Raspberry Pi, mais si vous pouvez reflasher le chargeur de démarrage avec une clé de chiffrement intégrée (qui est ensuite transmise au noyau), cela ne serait au moins pas sur la carte SD, donc c'est ' d déjouer une tentative pour le faire démarrer dans un émulateur.