Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Шифрование прошивки
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > ARM, 32bit
toweroff
Добрый день!
Есть бут, который принимает прошивку и пишет во внутреннюю флеш
Соответственно, хочется ее зашифровать
Кто что использует для этого и насколько эффективны и сложны в реализации разные методы?

Спасибо
ILYAUL
Цитата(toweroff @ Aug 18 2011, 23:14) *
Добрый день!
Есть бут, который принимает прошивку и пишет во внутреннюю флеш
Соответственно, хочется ее зашифровать
Кто что использует для этого и насколько эффективны и сложны в реализации разные методы?

Спасибо

А как сам проц будет выполнять зашифрованный код? laughing.gif Как Вы это себе представляете на аппаратном уровне - он же сам расшифровывать вроде как не умеет , по причине полной тупизны?
toweroff
Цитата(ILYAUL @ Aug 18 2011, 23:36) *
А как сам проц будет выполнять зашифрованный код? laughing.gif Как Вы это себе представляете на аппаратном уровне - он же сам расшифровывать вроде как не умеет , по причине полной тупизны?

наверное, я не совсем ясно выразил мысль sm.gif
конечно, "на лету" ничего расшифровываться не будет
буту скармливается зашифрованная прошивка, которую он расшифровывает и записывает во флеш, после чего передает по известному адресу управление
yashok
Я шифрую по алгоритму Triple DES (3DES). При заливке на ходу расшифровывается и пишется во флэш. Процы из серии lpc 17xx с прошивкой ~500 kB прошиваются чуть меньше чем за 6 мин.
Вся эта защита необходимо если перепрошивкой занимается конечный пользователь.
AlexandrY
Цитата(toweroff @ Aug 18 2011, 22:54) *
наверное, я не совсем ясно выразил мысль sm.gif
конечно, "на лету" ничего расшифровываться не будет
буту скармливается зашифрованная прошивка, которую он расшифровывает и записывает во флеш, после чего передает по известному адресу управление


Лучше сжать, а потом зашифровать. И зашифровать в режиме CBC по 3DES или AES. В начало вставить блок случайных данных. Потом все подписать хешем по SHA1.
На STM32F2 это все делается особо просто.
toweroff
у меня LPC2929
со сжатием интересно, спасибо за совет
единственное - памяти на борту только внутренняя контроллера, часть которой использутся под буферы
хватит оставшихся 16-20 кб на распаковку и дешифрацию?
AlexandrY
Цитата(toweroff @ Aug 19 2011, 10:25) *
у меня LPC2929
со сжатием интересно, спасибо за совет
единственное - памяти на борту только внутренняя контроллера, часть которой использутся под буферы
хватит оставшихся 16-20 кб на распаковку и дешифрацию?


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

Tanya
Цитата(AlexandrY @ Aug 19 2011, 11:48) *
Но для сжатия хотя бы в два раза бинарной прошивки объемом в пару сотен килобайт LZ подобным алгоритмом нужно минимум 64 Кб RAM.

А кусками?
=AK=
Цитата(toweroff @ Aug 19 2011, 16:55) *
хватит оставшихся 16-20 кб на распаковку и дешифрацию?

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

А если хочется, чтобы и просто, и быстро, то сделайте простой потоковый шифр на 32-битном LFSR. Для практики этого будет более чем достаточно, имхо.
AlexandrY
Цитата(Tanya @ Aug 19 2011, 10:56) *
А кусками?


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

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

Цитата(=AK= @ Aug 19 2011, 11:13) *
А если хочется, чтобы и просто, и быстро, то сделайте простой потоковый шифр на 32-битном LFSR. Для практики этого будет более чем достаточно, имхо.


RC4 будет быстрее чем LFSR. А применяется в серьезных технологиях VPN.
=AK=
Цитата(AlexandrY @ Aug 19 2011, 17:45) *
RC4 будет быстрее чем LFSR.

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

Цитата(AlexandrY @ Aug 19 2011, 17:45) *
А применяется в серьезных технологиях VPN.

Там оправдано, более того - необходимо применение более сложных алгоритмов, чем простейший LFSR.
AlexandrY
Цитата(=AK= @ Aug 19 2011, 11:23) *
Мне это неочевидно. Всегда думал, что самый простой и эффективный цифровой генератор псевдобелого шума - это LFSR


Нелинейный LFSR применяют в автомобильных радиобрелках, как известно, и в донглах типа eToken, где предельно мало RAM-а.
Но прокручивать там этот регистр приходится сотни раз! для одного сэмпла.
Tanya
Цитата(AlexandrY @ Aug 19 2011, 12:15) *
Ну так уменьшение heap-а в LZ алгоритмах это и есть фрагментация процесса сжатия. Она и ухудшает показатель сжатия.

Мне вот кажется, что прошивки мало отличаются одна от другой...
AlexandrY
Цитата(Tanya @ Aug 19 2011, 11:37) *
Мне вот кажется, что прошивки мало отличаются одна от другой...


В серьезных прошивках большая часть это ресурсы. Тексты, отладочная информация, шрифты, таблицы, звуки, файловые структуры... Совершенно разнородная информация.
Отличаться есть чем, хотя не понял к чему это утверждение в данном контексте.
Tanya
Цитата(AlexandrY @ Aug 19 2011, 12:58) *
В серьезных прошивках большая часть это ресурсы. Тексты, отладочная информация, шрифты, таблицы, звуки, файловые структуры... Совершенно разнородная информация.
Отличаться есть чем, хотя не понял к чему это утверждение в данном контексте.

Я имела в виду возможность использования одного и того же дерева. Кроме всего прочего, можно же менять (даже двигать) куски (фрагменты).
MrYuran
Цитата(AlexandrY @ Aug 19 2011, 11:48) *
Но для сжатия хотя бы в два раза бинарной прошивки объемом в пару сотен килобайт LZ подобным алгоритмом нужно минимум 64 Кб RAM.

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

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

2ТС: ознакомьтесь для начала с атмеловскими аппликациями
zltigo
QUOTE (MrYuran @ Aug 19 2011, 12:29) *
Естественно, мелкоконтроллерам до этого как до луны.

Да.
QUOTE
Ну и стоит ли геморрой свеч?

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

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

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

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

Но в общем как отправная точка, или просто почитать документацию - годится.
У меня к тому формату добавлено несколько команд, выходной файл сделан hex-образным.
AlexandrY
Цитата(MrYuran @ Aug 19 2011, 12:29) *
Вообще, не в ту сторону тему увели. Лучшие архиваторы, используя мощь многоголовых гигагерцев и мегабайтов, пакуют среднестатистический ехе-шник примерно вдвое.
Естественно, мелкоконтроллерам до этого как до луны.



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

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

На моих платформах всегда применяется сжатие для фирмваре, и даже несколько алгоритмов.
И как правило коэффициент сжатия больше 2-х даже на простых алгоритмах типа LZSS.
Поскольку часто апгрейд идет через GSM и другие медленные каналы то любые лишние 100K чувствуются.
toweroff
Спасибо всем за каменты
То есть, я так понимаю,
1. не столько важно зашифровать исходник, чем запаковать и зашифровать чем-то исходник
2. Просто зашифрованная прошивка тем же AES, 3DES поддастся анализу? (текстовых блоков нет, передаваемых подряд констант по внешнему каналу максимум 128 бит уже в рабочем девайсе)
3. Сама прошивка ~64 KB
4. Перестановка блоков прошивки (например, отдельное шифрование+сжатие блоков по 512,1К.2К) для каждого конкретного девайса может дополнительно помочь?
=AK=
Цитата(toweroff @ Aug 20 2011, 07:42) *
1. не столько важно зашифровать исходник, чем запаковать и зашифровать чем-то исходник

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

Цитата(toweroff @ Aug 20 2011, 07:42) *
2. Просто зашифрованная прошивка тем же AES, 3DES поддастся анализу? (текстовых блоков нет, передаваемых подряд констант по внешнему каналу максимум 128 бит уже в рабочем девайсе)

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

Цитата(toweroff @ Aug 20 2011, 07:42) *
4. Перестановка блоков прошивки (например, отдельное шифрование+сжатие блоков по 512,1К.2К) для каждого конкретного девайса может дополнительно помочь?

Нет.

Среди множества с виду "полезных для шифровки" действий значительная их часть не приносит ровно никакой пользы. Насколько я понял, это вещи довольно неочевидные доже для опытных специалистов, поэтому каждый серьезный способ шифрования подвергается долгому анализу.
Harbinger
Цитата(Tanya @ Aug 19 2011, 11:37) *
Мне вот кажется, что прошивки мало отличаются одна от другой...

Намёк понятен. sm.gif
Передавать не зашифрованную прошивку, а зашифрованную "разницу".
Это реализовывалось и в основном работает.
andrewlekar
Вообще самое правильное для удаленной прошивки - передавать скрипт для скриптового движка. При таком решении вся прошивка может байт 100 занимать.
cpl
Цитата(andrewlekar @ Aug 22 2011, 09:39) *
Вообще самое правильное для удаленной прошивки - передавать скрипт для скриптового движка. При таком решении вся прошивка может байт 100 занимать.

Что-то не совсем понятно, поясните как будет работать обновление ?
toweroff
Цитата(zltigo @ Aug 19 2011, 14:41) *
AES подлежит оптимизации (однажды на форуме была стихийно возникшая тема в которой выкладывал эти исходники хоть как-то оптимизипрванные под AVR).

можно посмотреть? полазил поиском AES* - пересмотрел несколько страниц, не нашел
хотя, конечно, более интересуют реализации, заточенные под 32-бит архитектуру
=AK=
Цитата(toweroff @ Aug 22 2011, 19:40) *
более интересуют реализации, заточенные под 32-бит архитектуру


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

Цитата(cpl @ Aug 22 2011, 15:41) *
как будет работать обновление ?

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


Ага-ага. Щас. Я глянул - LZ как LZ. Причем по древним боянным технологиям хранения ссылок назад. С поддержкой двухбайтовых ссылок назад. Я таких написался пятнадцать лет назад дофига.
zltigo
QUOTE (toweroff @ Aug 22 2011, 13:10) *
можно посмотреть? полазил поиском AES* - пересмотрел несколько страниц, не нашел
хотя, конечно, более интересуют реализации, заточенные под 32-бит архитектуру

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

то есть, вся адаптация под ARM того самого AVR231 сводится только к замене функции memcpy_z() ?
zltigo
QUOTE (toweroff @ Aug 22 2011, 14:10) *
то есть, вся адаптация под ARM того самого AVR231 сводится только к замене функции memcpy_z() ?

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

toweroff
Цитата(zltigo @ Aug 22 2011, 15:20) *
Разумеется нет

итого
берем атмелевский пример и не заморачиваемся? компилятор сам разберется с оптимизацией байтовых операций? sm.gif
zltigo
QUOTE (toweroff @ Aug 22 2011, 14:31) *
итого
берем атмелевский пример и не заморачиваемся? компилятор сам разберется с оптимизацией байтовых операций? sm.gif

Я теряюсь в понимании смысла написанного Вами sad.gif. Я выложил исходник. Можете откомпилировать и сравнить результат с оригинальным атмеловским. Обещаю, разница будет.
Что Вы при этом называете заморачиваться я не понимаю sad.gif
toweroff
Цитата(zltigo @ Aug 22 2011, 15:36) *
Я теряюсь в понимании смысла написанного Вами sad.gif. Я выложил исходник. Можете откомпилировать и сравнить результат с оригинальным атмеловским. Обещаю, разница будет.
Что Вы при этом называете заморачиваться я не понимаю sad.gif

упс.. прошу прощения, Вы файл, вероятно, чуть позже приложили
когда я писал ответ, то предполагал, что сказанное относится к оригинальному AVR231
теперь видна разница
Спасибо
zltigo
QUOTE (toweroff @ Aug 22 2011, 14:45) *
упс.. прошу прощения, Вы файл, вероятно, чуть позже приложили

Да, при первой отправке руганулся на расширение sad.gif - у меня на автомате создаются архивы *.rar.archive
toweroff
Цитата(zltigo @ Aug 22 2011, 16:08) *

тогда последний вопрос по Вашему примеру - там подключаются два файла - aes.h, aes_data.h
Первый, я так понимаю, "родной" атмелевский, а что во втором? Наверняка определение KEY_COUNT, но что еще?
zltigo
QUOTE (toweroff @ Aug 22 2011, 15:14) *
Первый, я так понимаю, "родной" атмелевский, а что во втором?
Наверняка определение 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
Цитата(zltigo @ Aug 22 2011, 16:33) *
Да. оно самое. Генерится автоматически тем, что у Атмела было под названием CREATOR.

ему (креатору) подсовывается конфиг
там ключи должны быть "with parity bits inserted"
непонятно - вручную дополнять, или что-то есть для автоматизации?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.