Уважаемые коллеги! Хочется узнать Ваше мнение по поводу надежности следующего решения. Дано: Объект защиты - микропрограмма (прошивка) устройства на базе МК AVR ATMega16x. Прошивка (~15кб) на выходе компилятора шифруется по некоторому алгоритму XOR-ROL-SWAP-NOT, строка для XOR фиксированная, 1024 байта. Зашифрованная прошивка отдается в публичный доступ. Пользователь при помощи примитивной программы-терминала (не содержащей какой-либо обработки данных) отправляет шифровку в устройство (его бутлоадеру), которое расшифровывает ее, проверяет CRC и (если совпало) запускает на выполнение. Считается, что исходная микропрограмма, шифратор и бутлоадер аналитику не известны. Требуется: обеспечить практическую невозможность получения исходной микропрограммы, чтобы отбить производителю железа желание делать "левые" устройства. Вопрос: насколько надежно описанное решение? Как изменится ситуация при наличии у аналитика нескольких версий прошивки (зашифрованных одинаково)? Заранее благодарю.
Если это гарантируется, то можно считать решение надежным, даже при наличии нескольких версий прошивки. Но: 1. Если устройство попадает в руки исследователю, можно считать, что все перечисленное станет известно. 2. Криптографы исходят из того, что как раз схема шифрования известна, неизвестны ее ключевые параметры. Исходя из этой предпосылки, нужно анализировать стойкость твоей схемы шифрования к взлому. Понимаю, что ответ слишком общий... но я бы подверг анализу схему именно с позиции п.2, в том числе анализу на предмет использования нескольких версий прошивки (я правильно понял, что в них используются разные ключи, а сама схема не изменяется?). Добавлено: 1. Слабым звеном мне лично кажется бутлоадер, насколько он защищен от исследования? 2. Если используется механизм общедоступного ключа, то при длине ключа 1024 можно пока считать решение надежным.
Почему не рассматривается загрузка в эмулятор? Прошивки обычно битами защиты, делающими крайне затруднительным считывание образа защищают при собственно прошивке.
Спасибо за мысли! Все дело в необходимости дать пользователю инструмент простого обновления микропрограммы (на будущее). Поэтому бутлоадер. Естественно, биты защиты чипа запрещают его считывание. Говорят, AVR с выставленными фьюзами можно прочитать только порезав лазером (т.е. биты флеша оголить и посмотреть). Меня как программиста такой вариант не беспокоит. По причине крайней нехватки памяти программ, я не могу использовать широко обсуждаемые здесь алгоритмы типа DES, RSA, GOST и пр. У меня есть порядка 20 операций на расшифровку и килобайт на ключ. Ключ, исходник прошивки и бутлоадер находятся у меня, т.е. равнодоступны злоумышленнику. Что Вы имеете в виду? Если я облегчу взломщику задачу: пусть применяется только XOR, в конце прошивки лежит CRC, некоторые места исходной прошивки могут быть "отгаданы" (таблица прерываний и т.п.). Насколько вероятнее станет взлом? Еще раз благодарю за советы.
Megavolt Прошивка имеет некий стандартный вид (хотя бы частично)? Если так, то это может быть использовано при отсеивании ключей, например, при их тотальном переборе. 20 операций не так уж и много для формирования алгоритма шифрования. ЗЫ Неплохо основать фирму, которая совершенно официально выполняла бы подобные виды анализа безопасности
Попробуй тогда TEA. Ксор нескольких прошивок с одинаковым ключем это слишком ненадежное решение. Рекомендую юзать TEA в CBC режиме, и в начало прошивки добавлять хотябы 8 байт salt
Megavolt Повторное (особенно многократное) использование чистого xor ключа - верный путь к его вскрытию А у тебя он только в шифрации кода аж 15 раз повторно используется Так что максимально усложняй комбинацию XOR-ROL-SWAP-NOT и делай ставку на недоступность алгоритма шифровки, благо фусёвая защита в AVR рулит Если часть алгоритма шифровки будет "промокашкой" то меняй её в каждой перепрошивке. Не совсем понятно ограничение "20 операций" Имхо в данном случае лучше сэкономить байты на xor части ключа. Неиспользуемые части таблицы прерываний лучше использовать под код/данные или забивать случайными числами
2 Y_Mur Код бутлоадера с перестановками сам является ключом. А вот это хорошая мысль - поправить безобразия штампов компилятора. Спасибо! 2 Crypto Естественно, первые 128 байт предсказуемы. Хотя это можно поправить.
Megavolt Всякую предсказуемость нужно по возможности сводить к нулю. Дополнение И я бы еще добавил перекодировку байт кода бутлоадера
Используй потоковый шифр RC4 - сам алгоритм для шифровки\расшифровки пишется несколькими командами а стойкость при ключе в 1024 будет достаточной
Megavolt Совмещение загрузки с расшифровкой это хорошо, но ничего не мешает разместить дополнительную функцию расшифровки в основной памяти: fuses защита от чтения там тоже есть, + больше возможностей усложнить алгоритм + возможность его обновления crypto Как раз лоадер при обновлении изменять нельзя - он зашивается до продажи девайса. Ultrin Faern в сущности xor с "упакованной" промокашкой - безусловно лучше чистого xor, но в данном случае есть возможность надёжно скрыть от прочтения нестандартный алгоритм расшифровки - имхо не стоит пренебрегать этим ЗЫ: Хотя в большинстве случаев можно просто написать новую прошивку на основе перехвата рабочих сигналов и совсем не возиться с расшифровкой авторской версии Вопрос только в том насколько профессиональны потенциальные конкуренты.
Y_Mur Мешает. На чипе 16к флеша. 1к-бут+15к осн. прошивка. Бут=асм+с, Прошивка=с+асм. В прошивке резервы ужаться еще есть, но и функционал нужно будет нарастить. В буте - почти некуда ужиматься. Согласен. Коллеги! А во сколько $, чел*час, юаней вы оценили бы взлом обсуждаемой защиты? Безотносительно стоимости девайса.
Можно ли использовать ADD ? Дело в том, что описанный тобою набор операций (XOR, NOT, SWAP, ROL) достаточно легко преобразуется. А вот если применять поочередно ADD и XOR - они образуют разные группы преобразований, и в принципе могут за достаточно небольшое количество операций создать достаточную для твоей задачи стойкость (кстати, упомянутый выше TEA именно это и делает - но тебе его мощность не нужна, можно просто его упростить). Да, и конечно где-то в самом начале прошивки добавь несколько случайных байт, рандомизирующих весь последующий поток - даже если прошивка изменилась на пару бит, в зашифрованном виде она будет "неузнаваема".
Не забывай требования RC4 к оперативной памяти : сколько её доступно алгоритму расшифровки автор треда вроде бы нигде не сказал ...
OLS Около 512 байт. Кстати, думаю, применяя ADD к ключу, можно избежать его повторного использования.
RC4 не очень подходит для этого случая, так как на одном ключе всегда дает одинаковую гамму, из чего вытекает свойство недопустимости шифрования двух открытых текстов на одном ключе. Как полумеру можно предложить иметь постоянную часть ключа, и изменяемую (находящуюся в загружаемой прошивке), но имхо так делать не стоит. Единственно верное рекшение - любой блочный шифр в CBC режиме + salt. TEA в данном случае будет попроще, хоть работает он медленее. К тому же он не требует кучу памяти для таблицы PRNG, и не требует развертки ключа.
Дык я и предлагаю перенести расшифровку в прошивку (она же всё равно стирается не сразу вся, а блоками) - сэкономишь место в буте и получишь обновляемый алгоритм расшифровки Как верно заметил crypto Если алгоритм нестандартен и ты не сделаешь в нём откровенных ляпов, то его взлом будет процесс творческий - и однозначно оценить трудозатраты на него проблематично. Но пока не ясен вопрос с трудозатратами на написание собственной прошивки на основе анализа функциональности девайса и перехвата некоторых сигналов. Имхо здесь может оказаться слабое место.
Y_Mur Говорю же, держать в основной прошивке какой-либо доп. код - места нет. К тому же, в начальный момент флеш вообще пустой - только бут. Принципы работы - общеизвестны, некоторые протоколы - будут опубликованы на сайте. Есть еще криптованный протокол обмена нескольких устройств в сети. Пока что вопрос стоит о защите от копирования.
Y_Mur Если цитировать без отрыва от контектста, то так: Бут в идеале пишется один раз и прошивается после тестирования девайса (только "своими"), либо вообще при изготовлении чипа (там гарантии неразглашения ATMELа). При этом в качестве основоной прошивки может заливаться некий selftest устройства. Потом все девайсы лежат на складе, по необходимости заливаются нужным вариантом функционала и отдаются потребителю. Склад и люди, которые будут заливать функционал, могут быть "чужими", поэтому отдавать им HEX и программатор резона нет.
