Шифрование прошивки, кто что использует Опции

[toweroff]

Добрый день!
Есть бут, который принимает прошивку и пишет во внутреннюю флеш
Соответственно, хочется ее зашифровать
Кто что использует для этого и насколько эффективны и сложны в реализации разные методы?

Спасибо

[ILYAUL]

Добрый день!
Есть бут, который принимает прошивку и пишет во внутреннюю флеш
Соответственно, хочется ее зашифровать
Кто что использует для этого и насколько эффективны и сложны в реализации разные методы?

Спасибо

А как сам проц будет выполнять зашифрованный код? Как Вы это себе представляете на аппаратном уровне - он же сам расшифровывать вроде как не умеет , по причине полной тупизны?

[toweroff]

А как сам проц будет выполнять зашифрованный код? Как Вы это себе представляете на аппаратном уровне - он же сам расшифровывать вроде как не умеет , по причине полной тупизны?

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

[yashok]

Я шифрую по алгоритму Triple DES (3DES). При заливке на ходу расшифровывается и пишется во флэш. Процы из серии lpc 17xx с прошивкой ~500 kB прошиваются чуть меньше чем за 6 мин.
Вся эта защита необходимо если перепрошивкой занимается конечный пользователь.

[AlexandrY]

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

Лучше сжать, а потом зашифровать. И зашифровать в режиме CBC по 3DES или AES. В начало вставить блок случайных данных. Потом все подписать хешем по SHA1.
На STM32F2 это все делается особо просто.

[toweroff]

у меня LPC2929
со сжатием интересно, спасибо за совет
единственное - памяти на борту только внутренняя контроллера, часть которой использутся под буферы
хватит оставшихся 16-20 кб на распаковку и дешифрацию?

[AlexandrY]

у меня LPC2929
со сжатием интересно, спасибо за совет
единственное - памяти на борту только внутренняя контроллера, часть которой использутся под буферы
хватит оставшихся 16-20 кб на распаковку и дешифрацию?

16 кБ это разве что на RLE алгоритм хватит.
Можно конечно в алгоритмах сжатия регулировать требуемый объем памяти.
Но для сжатия хотя бы в два раза бинарной прошивки объемом в пару сотен килобайт LZ подобным алгоритмом нужно минимум 64 Кб RAM.

[Tanya]

Но для сжатия хотя бы в два раза бинарной прошивки объемом в пару сотен килобайт LZ подобным алгоритмом нужно минимум 64 Кб RAM.

А кусками?

[=AK=]

хватит оставшихся 16-20 кб на распаковку и дешифрацию?

Используйте XTEA, ему совсем мало места надо.

А если хочется, чтобы и просто, и быстро, то сделайте простой потоковый шифр на 32-битном LFSR. Для практики этого будет более чем достаточно, имхо.

[AlexandrY]

А кусками?

Ну так уменьшение heap-а в LZ алгоритмах это и есть фрагментация процесса сжатия. Она и ухудшает показатель сжатия.

Есть алгоритм UCL который как утверждается не требует памяти на декомпрессию.
Но не пробовал.

А если хочется, чтобы и просто, и быстро, то сделайте простой потоковый шифр на 32-битном LFSR. Для практики этого будет более чем достаточно, имхо.

RC4 будет быстрее чем LFSR. А применяется в серьезных технологиях VPN.

[=AK=]

RC4 будет быстрее чем LFSR.

Мне это неочевидно. Всегда думал, что самый простой и эффективный цифровой генератор псевдобелого шума - это LFSR

А применяется в серьезных технологиях VPN.

Там оправдано, более того - необходимо применение более сложных алгоритмов, чем простейший LFSR.

[AlexandrY]

Мне это неочевидно. Всегда думал, что самый простой и эффективный цифровой генератор псевдобелого шума - это LFSR

Нелинейный LFSR применяют в автомобильных радиобрелках, как известно, и в донглах типа eToken, где предельно мало RAM-а.
Но прокручивать там этот регистр приходится сотни раз! для одного сэмпла.

[Tanya]

Ну так уменьшение heap-а в LZ алгоритмах это и есть фрагментация процесса сжатия. Она и ухудшает показатель сжатия.

Мне вот кажется, что прошивки мало отличаются одна от другой...

[AlexandrY]

Мне вот кажется, что прошивки мало отличаются одна от другой...

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

[Tanya]

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

Я имела в виду возможность использования одного и того же дерева. Кроме всего прочего, можно же менять (даже двигать) куски (фрагменты).

[MrYuran]

Но для сжатия хотя бы в два раза бинарной прошивки объемом в пару сотен килобайт LZ подобным алгоритмом нужно минимум 64 Кб RAM.

А для распаковки?

Вообще, не в ту сторону тему увели. Лучшие архиваторы, используя мощь многоголовых гигагерцев и мегабайтов, пакуют среднестатистический ехе-шник примерно вдвое.
Естественно, мелкоконтроллерам до этого как до луны. Ну и стоит ли геморрой свеч? Разве что как дополнительная степень защиты. Так для этого можно и попроще алгоритм применить.
Вот в ПЛИСах другое дело. Там часто встречаются длинные последовательности нулей и единиц, и даже простейшие методы позволяют существенно пожать прошивку.

2ТС: ознакомьтесь для начала с атмеловскими аппликациями

[zltigo]

Естественно, мелкоконтроллерам до этого как до луны.

Да.

Ну и стоит ли геморрой свеч?

Нет.

Разве что как дополнительная степень защиты. Так для этого можно и попроще алгоритм применить.

Да

Вот в ПЛИСах другое дело. Там часто встречаются длинные последовательности н улей и единиц, и даже простейшие методы позволяют существенно пожать прошивку.

Ну а поскольку у меня в прошивках контроллера встречается, как правило, прошивка FPGA, то пред шифровкой использую простейшее RLE подобное сжатие.

2ТС: ознакомьтесь для начала с атмеловскими аппликациями

Кода-то от него и отталкивался. Только там есть
- как минимум одна ошибка при обработке нештатых ситуаций(забыл какая конкретно, поскольку сразу все начал переписывать);
- все писано небрежно, а AES уж слишком в лоб . AES подлежит оптимизации (однажды на форуме была стихийно возникшая тема в которой выкладывал эти исходники хоть как-то оптимизипрванные под AVR).

Но в общем как отправная точка, или просто почитать документацию - годится.
У меня к тому формату добавлено несколько команд, выходной файл сделан hex-образным.

[AlexandrY]

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

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

С другой стороны сжатие скрывает вариации размера прошивки от версии к версии.
Вломщики как правило сразу ведут дифференциальный анализ прошивок, т.е. сравнение разных версий.
На основании размеров они решают че взламывать, а че нет. Где инженерные версии, а где релизные и т.д.

На моих платформах всегда применяется сжатие для фирмваре, и даже несколько алгоритмов.
И как правило коэффициент сжатия больше 2-х даже на простых алгоритмах типа LZSS.
Поскольку часто апгрейд идет через GSM и другие медленные каналы то любые лишние 100K чувствуются.

[toweroff]

Спасибо всем за каменты
То есть, я так понимаю,
1. не столько важно зашифровать исходник, чем запаковать и зашифровать чем-то исходник
2. Просто зашифрованная прошивка тем же AES, 3DES поддастся анализу? (текстовых блоков нет, передаваемых подряд констант по внешнему каналу максимум 128 бит уже в рабочем девайсе)
3. Сама прошивка ~64 KB
4. Перестановка блоков прошивки (например, отдельное шифрование+сжатие блоков по 512,1К.2К) для каждого конкретного девайса может дополнительно помочь?

[=AK=]

1. не столько важно зашифровать исходник, чем запаковать и зашифровать чем-то исходник

Что важно, а что нет - решать вам, под задачу. Если надо экономить время при передаче массива, то сжимать важно, если нет - то нафиг надо, только время зря тратить на распаковку и на написание сложного бутлодера.

2. Просто зашифрованная прошивка тем же AES, 3DES поддастся анализу? (текстовых блоков нет, передаваемых подряд констант по внешнему каналу максимум 128 бит уже в рабочем девайсе)

Это все из категории "неуловимого Джо" - никто вашу прошивку вообще анализировать не будет, если увидят, что она зашифрована. Анализу поддаются данные, для которых набрана статистика, а одиночный блок ломать - только время тратить.

4. Перестановка блоков прошивки (например, отдельное шифрование+сжатие блоков по 512,1К.2К) для каждого конкретного девайса может дополнительно помочь?

Нет.

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

[Harbinger]

Мне вот кажется, что прошивки мало отличаются одна от другой...

Намёк понятен.
Передавать не зашифрованную прошивку, а зашифрованную "разницу".
Это реализовывалось и в основном работает.

[andrewlekar]

Вообще самое правильное для удаленной прошивки - передавать скрипт для скриптового движка. При таком решении вся прошивка может байт 100 занимать.

[cpl]

Вообще самое правильное для удаленной прошивки - передавать скрипт для скриптового движка. При таком решении вся прошивка может байт 100 занимать.

Что-то не совсем понятно, поясните как будет работать обновление ?

[toweroff]

AES подлежит оптимизации (однажды на форуме была стихийно возникшая тема в которой выкладывал эти исходники хоть как-то оптимизипрванные под AVR).

можно посмотреть? полазил поиском AES* - пересмотрел несколько страниц, не нашел
хотя, конечно, более интересуют реализации, заточенные под 32-бит архитектуру

[=AK=]

более интересуют реализации, заточенные под 32-бит архитектуру

ChaCha выглядит привлекательно. Salsa20/12 тоже неплохо.

как будет работать обновление ?

Прикладное ПО выполнено в виде скрипта. Новый скрипт загрузил - вот и обновился.

[Rst7]

Есть алгоритм UCL который как утверждается не требует памяти на декомпрессию.
Но не пробовал.

Ага-ага. Щас. Я глянул - LZ как LZ. Причем по древним боянным технологиям хранения ссылок назад. С поддержкой двухбайтовых ссылок назад. Я таких написался пятнадцать лет назад дофига.

[zltigo]

можно посмотреть? полазил поиском AES* - пересмотрел несколько страниц, не нашел
хотя, конечно, более интересуют реализации, заточенные под 32-бит архитектуру

Да, там действительно была какая-то стихийно возникшая тема по оптимизации загрузчика, где на этом атмеловском исходнике тренировались.
А этот атмеловский исходник живущий у меня под ARM, с оптимизацией, но помнится, без какой-то особой оптимизации конкретно под ARM - в приложении. Хотя, возможно, это не последний вариант - то, что сейчас нашлось на одном из компьютеров.
memcpy_z(). замените на memcpy(). bint для ARM это int. Для AVR bint это unsigned char. Все остальное без изменений.

Прикрепленные файлы

 aes_atmel.rar ( 2.26 килобайт ) Кол-во скачиваний: 68

 

[toweroff]

Да, там действительно была какая-то стихийно возникшая тема по оптимизации загрузчика, где на этом атмеловском исходнике тренировались.
А этот атмеловский исходник живущий у меня под ARM, с оптимизацией, но помнится, без какой-то особой оптимизации конкретно под ARM - в приложении. Хотя, возможно, это не последний вариант - то, что сейчас нашлось на одном из компьютеров.
memcpy_z(). замените на memcpy(). bint для ARM это int. Для AVR bint это unsigned char. Все остальное без изменений.

то есть, вся адаптация под ARM того самого AVR231 сводится только к замене функции memcpy_z() ?

[zltigo]

то есть, вся адаптация под ARM того самого AVR231 сводится только к замене функции memcpy_z() ?

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

[toweroff]

Разумеется нет

итого
берем атмелевский пример и не заморачиваемся? компилятор сам разберется с оптимизацией байтовых операций?

[zltigo]

итого
берем атмелевский пример и не заморачиваемся? компилятор сам разберется с оптимизацией байтовых операций?

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

[toweroff]

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

упс.. прошу прощения, Вы файл, вероятно, чуть позже приложили
когда я писал ответ, то предполагал, что сказанное относится к оригинальному AVR231
теперь видна разница
Спасибо

[zltigo]

упс.. прошу прощения, Вы файл, вероятно, чуть позже приложили

Да, при первой отправке руганулся на расширение - у меня на автомате создаются архивы *.rar.archive

[toweroff]

тогда последний вопрос по Вашему примеру - там подключаются два файла - aes.h, aes_data.h
Первый, я так понимаю, "родной" атмелевский, а что во втором? Наверняка определение KEY_COUNT, но что еще?

[zltigo]

Первый, я так понимаю, "родной" атмелевский, а что во втором?
Наверняка определение KEY_COUNT, но что еще?

Да. оно самое. Генерится автоматически тем, что у Атмела было под названием CREATOR.
Выглядит так:

CODE

//--------------------------------------------------------------------------
// File:           aes_data_usm3.h
// Created:        Sun Apr 27 17:15:16 2006

// Description:    File contains the settings to configure the boot loader
//                    according to the configurations used in the encrypted file.
//--------------------------------------------------------------------------

#ifndef _AES_DATA_H
#define _AES_DATA_H

#define PAGE_SIZE             512
#define FLASH_SIZE            131072
#define CRC_CHECK             1
#define SIGNATURE             0xXXXXXXXX
#define FRAME_BUFFER_SIZE     532
#define INITIALVECTOR_3       0xXXXXXXXX
#define INITIALVECTOR_2       0xXXXXXXXX
#define INITIALVECTOR_1       0xXXXXXXXX
#define INITIALVECTOR_0       0xXXXXXXXX
#define KEY_COUNT             3
#define OWNER_STRING          "USM3"


#endif //_AES_DATA_H
//--------------------------------------------------------------------------
// Description:    AES key table for a proper decryption of
//                 the file encrypted using the same configurations.
// Keys used:      KEY1 = , , , , ,
//                 KEY2 = , , , , ,
//                 KEY3 = , , , ,
//--------------------------------------------------------------------------

#ifndef _AES_KEYS_H
#define _AES_KEYS_H

const unsigned char kTable[32] =
{
    0xXX, 0x39, 0x58, 0x51, 0xXX, 0xb7, 0x3e, 0xXX,
    0x9f, 0xc0, 0x60, 0xe7, 0xce, 0x8e, 0x1f, 0x6d,
    0xba, 0x68, 0x1e, 0xac, 0x20, 0xdd, 0x10, 0x26,
    0x83, 0xXX, 0x42, 0x2d, 0xca, 0x86, 0xXX, 0xXX,
};


#endif //_AES_KEYS_H

[toweroff]

Да. оно самое. Генерится автоматически тем, что у Атмела было под названием CREATOR.

ему (креатору) подсовывается конфиг
там ключи должны быть "with parity bits inserted"
непонятно - вручную дополнять, или что-то есть для автоматизации?