Насколько легко взломать следующую защиту от копирования? [закрыто]

Я пытаюсь защитить от копирования некоторую работу - загрузочную SD-карту, загружающую ядро ​​Linux на устройстве ARM (Raspberry Pi). Я использую этот подход:

1. Подход использует initrd для монтирования зашифрованной корневой файловой системы.
2. Initrd генерирует пароль файловой системы в соответствии с CID SD-карты. (используется хеш-функция, еще не определилась с md5 или sha1). Initrd попытается смонтировать файловую систему, используя этот сгенерированный пароль.
3. Теперь вот самая интересная / подозрительная часть: сам initrd зашифрован с помощью пользовательской функции C, в основном каждый байт XOR-кодируется с помощью специального генератора псевдослучайных данных. Ядро модифицировано, чтобы иметь ту же функцию шифрования, которая работает как расшифровщик.
4. Сама система урезана, поэтому нет возможности использовать клавиатуру или внешнее хранилище. Одно приложение работает в полноэкранном режиме.

Таким образом, после того, как загрузчик загрузит ядро ​​и initrd, ядро ​​дешифрует initrd и выполняет свой скрипт init, который сгенерирует пароль и смонтирует корневую файловую систему.

Мой вопрос: насколько легко было бы сломать эту настройку (расшифровать корневую файловую систему и заставить ее загрузиться с любой SD-карты)? Какие самые слабые места? Насколько легко декомпилировать ядро ​​и найти эти пользовательские функции шифрования?

РЕДАКТИРОВАТЬ: Вот некоторые исправления, чтобы не тратить время на очевидные вещи:

1. Корневое устройство будет зашифровано с помощью LUKS (aes256), а ключ будет сгенерирован некоторыми функциями HMAC с использованием CID SD-карты и некоторого количества соли.
2. Псевдослучайный алгоритм для шифрования initramfs на самом деле будет RC4, просто ключ будет сгенерирован с помощью некоторой пользовательской функции, потому что если я просто сохраню ключ в байтовом массиве, это сделает его чрезвычайно простым для извлечения (да, это безопасность через неизвестность) но другого пути, похоже, нет).
3. Я понимаю, что если с помощью эмулятора SD-карты кто-то может запустить копию этой системы, это нормально для меня, потому что это довольно сложно, и никто не может этого сделать (также никто не захочет иметь дело с эмуляторами)

Насколько легко было бы сломать эту настройку (расшифровать корневую файловую систему и заставить ее загружаться с любой SD-карты)?

То, насколько сложно «сломать» ваши настройки, зависит от количества бит энтропии в любом методе, который вы используете для подписи / шифрования самой файловой системы (поскольку это определяет общее количество уникальных комбинаций, которые можно использовать для перебора). пароль).

Какие самые слабые места?

Без сомнения, использование предопределенного CID в качестве пароля, а также использование пользовательской функции генерации псевдослучайных чисел.

ИДС на SD карту только должен быть только для чтения, но это не редкость , чтобы найти незащищенные устройства флэш - памяти в этот день и возраст. Некоторые люди даже продемонстрировали способность перезаписывать CID на определенных SD-картах. Это упростит взлом паролей, особенно если вы просто эмулируете SD-карту после клонирования вашей (что вы, возможно, захотите рассмотреть).

Наконец, использование любого типа генератора псевдослучайных чисел уже имеет некоторые недостатки, именно потому, что он не случайный - есть причина, по которой он называется псевдослучайным . Возможно, лучше использовать предварительно сделанный зашифрованный загрузчик (например, TrueCrypt или LUKS, которые оба работают на Raspberry Pi) и избегать необходимости каких-либо модификаций ядра вручную.

Насколько легко декомпилировать ядро ​​и найти эти пользовательские функции шифрования?

Очень сложно что-то декомпилировать. И наоборот, разборка скомпилированного приложения часто бывает тривиальной, и есть много инструментов, которые можно использовать, чтобы помочь с обратной сборкой обратно на другой язык более высокого уровня. Если злоумышленник имеет доступ даже к скомпилированному ядру, анализировать что-то вроде генератора псевдослучайных чисел, вероятно, тривиально, если код специально не запутан.

TL, DR : не изобретайте колесо, когда дело доходит до шифрования и безопасности, придерживайтесь проверенного и верного. Есть несколько вариантов шифрования полного диска, которые уже доступны, и было продемонстрировано, что они отлично работают на Raspberry Pi. Я бы не использовал CID SD-карты в качестве своего рода «пароля» - даже если его нельзя изменить, существуют способы подделки этого значения.

Защита от копирования уже включена в спецификацию SD-карты как CPRM .

Кто-то квалифицированный не будет иметь больших проблем, взломав это. Было бы относительно легко загрузить SD-карту под эмулятором, а затем просто прочитать ключи из оперативной памяти. Затем они публикуют версию без защиты от копирования в Pirate Bay (и т. Д.), И все.

В качестве альтернативы используйте эмулятор для ввода шелл-кода в работающую эмулированную систему. Затем используйте работающую систему, чтобы скопировать дешифрованные rootfs (или прочитать ключи, используя dmsetup table --showkeysи т. Д.)

Быстрый поиск обнаруживает существование эмуляторов Raspberry Pi , поэтому часть работы уже выполнена.

У вас есть другая проблема, в частности это:

Ядро модифицировано, чтобы иметь ту же функцию шифрования, которая работает как расшифровщик.

Любой, кому вы распространяете это, имеет право на исходный код ядра в соответствии с условиями GPL. Таким образом, вам не нужно разбирать его, вы можете просто использовать, diffчтобы найти дополнительную функцию.

(Не то, чтобы найти его с помощью разборки было бы так сложно, как вы можете, например, проверить по сравнению со стандартным ядром)

Я не совсем знаком с загрузочным кодом Raspberry Pi, но если вы можете перепрошить загрузчик встроенным криптографическим ключом (который затем передается ядру), этого по крайней мере не будет на SD-карте, так что попытаться заставить его загрузиться в эмуляторе.