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

[toweroff]

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

Спасибо

[toweroff]

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

[AlexandrY]

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

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

[MrYuran]

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

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

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

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

[zltigo]

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

Да.

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

Нет.

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

Да

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

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

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

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

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

[toweroff]

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

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

[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"
непонятно - вручную дополнять, или что-то есть для автоматизации?