Для 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. Думаю, что эта функция написана не дилетантами и многократно проверена специалистами по криптографии.

Сообщение отредактировал osnwt - Mar 7 2006, 21:17

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

Типичный генератор вызлядит так:
#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?