Для AVR, с шифрованием по ГОСТ28147-89,
помещается в блок 2kWord, грузит файл из UART.
+ утилитка под Windows для преобразования .hex файлов FLASH и EEPROM в шифрованный файл, и утилитка для пользователя для загрузки в кристалл.
Целый год мечтал сделать.

А теперь можно нескромный вопрос - где ключики держатся?

Ключи шифрования задаются в программе для подготовки файла. Она пользователям не распространяется.
И в программе самого загрузчика. А эта программа прошивается производителем, с битами защиты.
В программе для ПК для обновления прошивки которую юзает юзер никаких манипуляций с шифрованием нет.
Ко всему прочему добавим избыточность со случайными числами для повышения криптозащиты.

Раз уж речь пошла про интим с нескромными вопросами , я тоже хочу задать такой же нескромный вопрос:

Чем написанный загрузчик функционально отличается от двух давно существующих Application Notes от Atmel, реализующих всё в точности то же самое, включая случайные nonsense records, за исключением того, что в них используется DES, 3DES и AES, а не гостовский алгоритм? Всё остальное в точности идентично, включая объем.

PS. Вопрос не случаен, так как я тоже написал загрузчик той же функциональности, но использующий USB для любой меги, начиная с 32 (критичен размер бут-блока - еле-еле удалось втиснуться в 4 килобайта, драйверов PC не надо - это HID устройство). Правда, я его еще и расширил функционально в некотором смысле, введя дополнительные возможности, отсутствующие в AppNotes. Может, есть что-то ещё, что можно туда вставить?

А сколь "случаен" сей генератор? Чем проверялось? Как правило, на свойствах таких "генераторов" и строят атаки....

osnwt: ничем, только другой алгоритм шифрования и Codevision вместо IAR.
А как ты мегу к USB подключаешь? Через какую микруху? Любопытно. HID - т.е. как накопитель на FLASH-карте для компа?

Evgeny_CD: Данный вопрос не беспокоит, мы не радары военные создаем

Напрямую через 3 резистора (при трехвольтовом питании), либо через 4 резистора и два стабилитрона (при пятивольтовом). USB реализуется программно, см. эту тему.

Вот пример схемы с сайта разработчика драйвера (эта штука работает, как стандартная клавиатура):




HID - это Human Interface Devices, один из стандартных USB классов. Накопители - это Mass Storage Devices, тоже стандартный класс, но не HID. HID не поддерживает USB bulk transfer type, необходимый для Mass Storage, и не обеспечивает таких скоростей обмена в силу своего предназначения.

С точки же зрения удобства написания устройств в формате HID это действительно удобно для низкоскоростного обмена, так как не требуется писать драйвер для PC - работает стандартный от Microsoft (на Win98, 2000 и выше). Также работает под Unix/Linux. Работа из приложений реализуется через стандартный HID API (функции HidD_*), либо просто через CreateFile/ReadFile/WriteFile/Close.

И, что особенно приятно, аппаратные затраты минимальны. Код драйвера занимает меньше 2-х килобайт и отлично документирован. Ограничения известны и некритичны. Самое существенное - это кварц на 12 MHz и необходимость запрещать прерывания не более, чем на 20 циклов. Всё обрабатывается в коде прерывания, за исключением пользовательских функций.



В указанном контексте случайные числа - это просто цифровой "шум", вставляемый между значимыми блоками данных для затруднения подбора ключей. Реально важны числа при генерации ключей алгоритма шифрования, а там используется rand() из стандартной библиотеки C. Думаю, что эта функция написана не дилетантами и многократно проверена специалистами по криптографии.

:-) Они пишутся максимально просто. В лучшем случае используются достаточно правильные
коэффициенты типа Миллера и подобных для получения более-менее приличного периода
повторения.

Типичный генератор вызлядит так:
#define MULTIPLIER 0x015a4e35L
#define INCREMENT 1

static long Seed = 1;

/*---------------------------------------------------------------------*

Name rand - random number generator

Usage int rand(void);

Related
functions usage void srand(unsigned seed);

Prototype in stdlib.h

Description rand uses a multiplicative congruential random number
generator with period 2^32 to return successive pseudo-
random numbers in the range from 0 to 2^15 - 1.

The generator is reinitialized by calling srand with an
argument value of 1. It can be set to a new starting point by
calling srand with a given seed number.

*---------------------------------------------------------------------*/
int rand(void)
{
Seed = MULTIPLIER * Seed + INCREMENT;
return((int)(Seed >> 16) & 0x7fff);
}

Впечатляет?

Не очень, поскольку эта формула для RAND мне знакома года примерно с 1984, когда я видел ее в дизассемблированном мной интерпретаторе BASIC для МикроЭВМ "Электроника Д3-28" (если кто помнит такую машинку). Правда, там использовалась плавающая арифметика (ибо, была реализована микропрограммно), но сути дела это не меняет.

Вопрос правильного подбора коэффициентов, период повторения и количество уникальных значений - это все понятно. Вопрос лишь в том: "Точно ли такой алгоритм используется, скажем, в стандартной библиотеке C"?

Спорить не буду, так как не специалист по криптографии и не ковырял библиотечные функции. Но замечу, что это - не в "лучшем случае". В лучшем кое-где используются отдельные датчики случайных чисел, основанные на физических принципах (шумы p-n перехода, к примеру). Вряд ли в бытовых PC, конечно. Но можно было бы наверняка придумать что-то получше.

Читал интересный рассказ на эту тему. Один товарищ решил реализовать супер-классный алгоритм генерации случайных чисел. Взял несколько разных алгоритмов и завел выход одного на вход другого, и т.п. Каково же было его удивление, когда его алгоритм при первом же запуске зациклился примерно на пятом "случайном" числе

osnwt: потрясающе красивое решение!

Удивительнее то, что работающее, и работающее прилично.

Эксперименты с программным USB (как и с программным сетевым адаптером для витой пары) проводились давно. Для AVR USB первым написал Igor Cesko. То был код на ассемблере, не очень удобный для повторения или развития. Но он был первым. Сейчас это - Appnote на сайте Atmel.

А Christian Starkjohann написал свой вариант, который, во первых, более оптимален с точки зрения приложения (много чего выполняет непосредственно "на лету" - интересная заметка на эту тему есть на сайте автора). Во вторых, он документирован. Известны его API, особенности и ограничения. Его стало можно использовать в собственных разработках. И, кроме того, с автором исключительно приятно работать. Мы с ним успевали порой по 5-6 пар писем в день (точнее, вечер) обменяться в ходе работ над IAR портом. В результате была выловлена одна особенность, связанная с обработкой процесса установки соединения. Автор доработал его, попутно сократив в объеме (!), но я, бессовестный, уже сутки не могу добраться и проверить на железе работу этого исправления.

Всё, бросаю писанину и продолжаю собирать свой очередной макет для проверки кое-каких идей. Тогда и драйвер проверю.

Алгоритм не стандартизирован никак. Более того, никак не гарантирована его псевдослучайность
для повторения. Предыдущий пример взят из реальной жизни - это Borland.
Ниже вариант 'послиднее', это IAR. Можете продолжить исследования - на более доступных
в исходных текстах библиотеках.



Я в курсе. Осталось решить вопрос, как Вы сможете повторить сию последовательность для
расшифровки :-))).
Ну а 'получше' уже придуманы, только для сишного rand они не используются.

Да я это всё понимаю. Делать аппаратные датчики в ширпотребовских PC никто не станет.


Да нет, спасибо Я же говорил, что не являюсь специалистом по криптографии.


Ну, это вопрос не ко мне. В текущих аппноутах это используется лишь как шум, а не как средство защиты. Основная защита тут - огромное количество переборов, если исключить выделяющиеся паттерны и т.п.

Но вообще-то, такие вещи классически ломаются совсем иначе. Догадываясь, что могло потенциально использоваться для написания такого бута, можно сконцентрировать атаку совсем на другом направлении. Например, на потенциальном переполнении входного буфера, что в исходниках от Atmel представляет вполне очевидную дыру. Правда, получится ли ей воспользоваться - еще вопрос. Но сформировать входной фрейм так, чтобы загрузчик улетел в определенном направлении (на определенный адрес) можно вполне. И какое при этом будет его состояние - неизвестно. Потому я предпочел поправить такие вот места, чем ломать голову над правильностью ключей. Уж мои-то самоделки явно ломать никто не станет - дешевле купить готовое или разработать самому :-)


Когда-то и 3DES был запрещен, поскольку госагенства не имели ресурсов для его вскрытия. Сейчас с этим проще. Может, и продвинутые алгоритмы и в стандартные библиотеки когда-нибудь попадут.

а можно ли выложить порт под IAR?

Порт для IAR интегрирован в основной исходный текст драйвера с помощью #ifdef и т.п.
Он работоспособен, но есть еще одна проблема (не привязанная к порту IAR, а общая), прокомментированная вот так:

- We need a delay between the SET ADDRESS request until the new address
becomes active. This delay was handled in usbPoll() until now. Since the
spec says that the delay must not exceed 2ms, previous versions required
aggressive polling during the enumeration phase. We have now moved the
handling of the delay into the interrupt routine.

Проблема носит косметический характер в 90% случаев, но для оставшихся немного неудобна, хотя и обходима. Я только что проверил очередную версию - кое-что там еще не то.

Я надеюсь, что в ближайшее время эта проблема будет решена или документирована, после чего версия драйвера с возможностью компиляции под IAR появится на официальном сайте.

Уж коль скоро тут была затронута тема случайных чисел

http://www.ozon.ru/context/detail/id/1454378/
М. А. Иванов, И. В. Чугунков
Теория, применение и оценка качества генераторов псевдослучайных последовательностей. Книга 2
Серия: СКБ - специалисту по компьютерной безопасности
Издательство: КУДИЦ-Образ, 2003 г.
Мягкая обложка, 240 стр.
ISBN 5-93378-056-1, 5-93378-047-2
Тираж: 3000 экз.

Я в своём загрузчике сделал простое шифрование.
Седлал таблицу на 256 байт в которой байты переставлены случайным образом местами. Пропускаю через таблицу хекс
и пересчитываю CRC для каждой строки хекса. Получаю закодированный хекс.
В загрузчике обратная таблица сидит которая декодирует хекс.
Прога для компа просто передаёт хекс построчно.(переделал бут от PLLC)

Как думаете надёжная такая простая защита?

Т.е по сути вся прошивка разбивается на куски по 256 байт, внутри каждого куска - тусовка байт, но закон тусовки одинаков для всех блоков? НЕТ!

Помнится, у DALLS был 51 процессор, у которого была шифровальная (XOR) таблица на 256 байт (для защиты прошивки во внешней памяти). Некоторое время назад я читал статью, в которой рассказывался метод хака такой защиты. Сейчас найти ее не могу.

В общем, пионЭров такая защита распугает, профи - едва ли. Ну а не дай бог в руки попадет несколько экземпляров прошивки для девайсов с разными ключами...

А я слышал, что есть фирма, специализирующаяся на чтении прошивок PIC, AVR и всяких альтер. Стоит эта услуга около $5000. Насколько это соответствует истине - не знаю, но допустить такую вероятность могу.

Нет прошивка на куски не разбивается.
Таблица одна для всй прошивки.
Работает так
пример 01h->таблица->FBh.
Таблица сформирована случайно.

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

Как я понял, это простой подстановочный код, где для каждого байта XX в соответствии находится байт YY. Для всех XX будет замена исключительно на YY. Всё равно, что переобозначить буквы в алфавите.

В тексте такие подстановочные шифры вскрываются на паре предложений по статистической вероятности встречи разных букв в обычном тексте. Тут, я думаю, тоже начать можно с этого. Реально же это существенной защиты не дает.

Интересно, какой смысл изобретать велосипеды? Не проще ли взять готовые математически обоснованные методы, к тому же, с исходниками и т.п. и просто тупо использовать их?

Или, если уж хочется по...ся, то тогда попробовать реализовать нечто наподобие системы шифрования с открытым ключом. Есть приватный и публичный ключи. Шифруется публичным, а расшифровывается внутри приватным. Просто публичный ключ выпускать нельзя тоже, ибо, можно будет при отсутствии должных мер просто зашить свою аппликуху и вычитать все остальное, например, ключ дешифровки (если не предусмотрено защиты от LPM бута).

IMHO, трата времени - более устойчивого алгоритма, чем созданный профессионалами и математически проверенный DES, 3DES, AES, и т.п. нам, дилентантам в этой области, все равно не создать. Так стоит ли заморачиваться всякими детскими играми в XOR и переставлялки?

Ответ автору топика: выражаю огромный респект, что бы ни говорили шифрование по ГОСТ более криптоустойчиво, нежели DES и прочие аналоги, ибо ГОСТ строится на теории элиптических кривых, да и сами профессионалы криптоанализа не видят в DES будущего...

P.S. а вскрытие XOR было в одной из задач студенческиой олимпиады по программированию, 2 команды решили задачку за 40минут. (разумеется если не XOR'ить c "одноразовым блокнотом").

Вопросы:
1) использовалась ли общая структура кода имеющихся атмеловских аппноутов лишь с заменой алгоритмов шифрования?
2) какой объем кода получился у скомпилированного файла алгоритма дешифровки?
3) каким компилятором (Atmel использует IAR)?

Просто интересно сравнить размер кода всех трех вариантов (два от атмела и этого). Разумеется, смысл сравнивать будет лишь в случае идентичности или близости подходов.

ЗЫ. Только написал про ключи с открытым кодом... Заглянул на предмет гостовского - а это оно и есть :-)

ЗЗЫ. 2kWord - это именно 2 килослова (4 килобайта), или 2 килобайта (1 килослово)?

Это к AlexanderY. Они этим серьезно занимается

Чипы на куски режут что ли?


не создать, но зато есть еще один фактор в криптозащитах - знание алгоритма шифрования. Без знания алгоритма, ломать становится еще сложнее. Поэтому можно помимо или вместо известных алгоритмов шифрования применять несколько "неизвестных" широкой публике алгоритмов шифрования по какой-то не очень сложной мат. формуле (тот же XOR не повредит).

Где Вы видели ГОСТ на алгоритм криптографического преобразования данных, который бы использовал эллиптические кривые?

Вопрос давно выяснен. Стойкость алгоритма шифрования, где основным "секретом" является сам алгоритм, равна времени, за которое можно мотивировать профессионала

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

Выше названный ГОСТ таким и является. Обычно бывает полезно читать не только КОНКРЕТНЫЕ алгоритмы, которые описаны в каком-либо стандарте, НО и на основе чего эти алгоритмы строятся. Вот видите, словосочетание "теория эллиптических кривых" обычных инженеров сбивает с толку, поэтому в стандарте содержится всего-лишь инструкции по использованию, без обоснований и доказательств эффективности. а DES? DES был придуман для использования внутри одной фирмы... по СЛУЧАЮ он оказался очень даже удачным и разошёлся бешеной популярностью, т.к. соответствующие органы не успели его "взять под свой контроль". DES очень удачный алгоритм, НО он не был построен на основе КРУТОГО математического аппарата, в результате при неумелом использовании он например может давать "слабые ключи". существуют нехилые оптимизации по его "грубому взлому". и пр. В околокриптографических кругах иностранные эксперты облизываются на ГОСТ =)

ГОСТ28147-89 не имеет отношения к эллиптическим кривым.
Это симметричный алгоритм шифрования, сделанный на основе сетей Файстеля.
На сегодня нет явных доказательств того, что схема шифрования ГОСТ сильнее схемы шифрования
DES (я не о длине ключа, а собственно о криптосхеме). Криптосхемы DES и ГОСТ весьма похожи.
Нет открытых данных о влиянии содержимого узлов замены ГОСТ на его криптостойкость. Может с какими-то узлами замены ГОСТ сильнее, а с какими-то - слабее.
У ГОСТ вместо битовой перестановки применен циклический сдвиг - это явно слабее. Но раундов больше - это сильнее.

В режиме TripleDes DES по прежнему считается достаточно стойким.

Может быть Вы путаете ГОСТ28147-89 с ГОСТ Р 34.10-2001 (алгоритм ЭЦП на основе эллиптических кривых)?

С уважением,
lvitaly

Опа...признаюсь, был неправ. Это я 2001 восхвалял.

Рановато Вы восхваляете алгоритм, основанный на эллиптических кривых. Этот алгоритм еще не выдержал проверку временем, в отношении такого класса алгоритмов пока не проведено такого количества исследований, как на основе дискретного логарифмирования, к примеру.
Косвенным подтверждением этого факта может служить то, что никто не бросился резко переходить с алгоритма DSA на алгоритм ECDSA. Причины же смены стандарта (перехода на эллиптику) у нас в России лежат не в математической плоскости, поверьте.

Понаблюдайте за PKCS#13. Когда он появится в более или менее стабильной редакции - мне кажется, что можно думать о эллиптике более практично.

Однако мы перемещаемся в зону offtop, поэтому если есть интерес продолжать дискуссию - просьба перейти в PM.

С уважением, lvitaly