Прошу помощи у коллег кто сталкивался с подобным противоречием..

Если ставить бит защиты от считывания- то он автоматически блокирует запись в память. ( Например чтобы не закатали через бутлоадер утилитку по считыванию памяти, такова идея защиты разработчиков ST)
Блокирует из любого источника или только со стороны бутлоадера?
Кажется на первый взгляд из любого, т.к через SWD также нельзя записать ничего.
При этом также ничего нельзя писать в память из приложения, те эмуляция eeprom для хранения настроек не возможна.. Или это не так?


Если мы хотим сделать собственный бутлоадер, то как нам закрыть доступ из встроенного?
и если мы отключили в программе swd то к swd нельзя ли подключиться до инициализации портов, и делать через него что-то ? (например читать память..)

...Если мы хотим сделать собственный бутлоадер, то как нам закрыть доступ из встроенного?
Просто при старте не заходите в режим встроенного бутлоадера. Пишите собственный и загружаете программу им.

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

Порты выделяемые под SWD, JTAG могут использоватся рабочей программой так как вы их назначите. SWD не будет доступен, если вы не определите
выделенные для него порты при иницилизации. Также установка коде протекта не дает вам возможность ипользовать порты для отладки, даже если вы их не переназначили и оставили в режиме для отладки.

Насколько я понимаю, эти фьюзы запрещают программирование извне или из программы в SRAM. Программа из флеша может писать во флеш

Не совсем так, или совсем не так. Фьюзы коде-протект (к-п) запрещают не только программирование извне, но и отладку и считывание программы. С установленным к-п вы можете только стереть, затем делать запись. Если пишите свой загрузчик, то наверное вы его защищаете и ставите к-п. В этом случае вы можете загружать рабочую программу в озу и прошивать флешь и таким образом будете делать абдейт вашего девайса. Загрузчик может быть написан таким образом, что сам устанавливает к-п по завершению загрузки. Но это еще не все. Появляется бэк-дор. Поскольку ваш загрузчик и загружаемая программа пишутся в открытом коде то есть вероятность, что продвинутые парни могут легко вскрыть это. Так как чип уже к-п, но ваш загрузчик пишет программу для абдейта в озу. По этому требуется криптовать загружаемую программу для большей уверенности.

Можно. Была подобная тема, когда человек случайно вырубал JTAG в загруженной в чип программе и никак не мог его прошить.
Ему посоветовали подать на boot0 и boot1 комбинацию, запускающую заводской uart-bootloader, который, как известно, не отключает JTAG и ... спокойно подключиться по JTAG.

Это в том случае, если коде-протект не установлен. Если установлен подключиться по JTAG не получиться.

Получится то наверное получится, но прочитать прогу - нет. А перед записью сотрется флеш.

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

Соответственно, нужна подпись вашей прошивки - чтобы загрузчик не залил что-то левое, которое к примеру передаст код загрузчика наружу

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

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


Нельзя. Читаем даташит на stm32f100x

Это понятно и это не то. Вы ведь как-то делаете загрузку програмы (абдейты) через ваш згрузчик, кторый под протектом. И если у вас не закриптована загружаемая программа, то протокол снять не проблема и разобрать что к чему не трудно. Затем загрузить прогу для вывода данных в порт и все.

Не, стоп. Вы говорили про бекдор - загрузка сторонней проги в SRAM и вычитка загрузчика? Судя по даташиту, такой возможности нет.

Далее. Основная программа должна быть подписана одним из алгоритмов цифровой подписи. Этого уже достаточно, чтобы через мой загрузчик нельзя было залить троянца (который к примеру сбросит код загрузчика вовне для анализа и выделения ключей).

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

Подключится можно, но считать прошивку нельзя пока не стёрты биты защиты.
Более того можно стереть чип, а записать новое всё-равно не получится т.к. биты защиты не стираются командой chip-erase как в AVR.
Нужно специально снимать биты защиты. Я не далее как позавчера на этот прикол наткнулся.

Даташит тут не причём. Проблема, бек дора образуется при написании вашего собственного загрузчика, в отличие от апаратного.

А вот теперь вопрос к тем, кто пишет свой загрузчик. Вы подписываете одним из алгоритмов цифровой подписи? Или нет?
И сколько ресурсов вы отдаете под это?


Похоже, только начинаете с ними работать.

Подписываю. Ресурсы именно на подпись не считал. Загрузчик с шифрованием и цифровой подписью, прием по rs232 и еще несколько плюшек на gcc у меня занимает почти 8к. Флаги оптимизации подобрал, писал не сильно заморачиваясь на "С с классами".

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

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

Алгоритмов много, я применяю гостовский. Он симметричный, т.е. прошивка подписывается ключом, который должен знать загрузчик. Есть ассиметричные алгоритмы - с открытым и закрытым ключом. В таком случае подпись может проверить кто угодно по открытому ключу. Но они более прожорливы - как по ресурсам, так и по объему программы.

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

Гм, цифровая подпись обычно имеется в виду именно криптографическая. Иначе говорят "контрольная сумма".

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

Что касается ресурсов - гостовские подпись и шифрование используют общий код, так что оверхед по объему загрузчика незначителен

Цифровая подпись есть цифровая подпись и ничего не меется в виду, что то сродни MD5, иначе с вашими "имеется в виду" полный бардак. Возможно для вас криптография - сложная штука по этому и пользуетесь гостовской с низкой стойкостью. Однозначно, незначительный оверхед = низкая стойкость.
Нестандартный с хорошей вероятностью легко ломается - ... это вас кто-то напугал, чтобы пользовали гостовский. Все же считается. Но в этой теме не об этом.

В целом забавная беседа%)... С одной стороны человек знающий ассимитричные и гостовские алгоритмы и использующий понятие "цифровая подпись" в значении в котором ее использует 99% мира. С другой стороны человек именующий цифровой подписью контрольную сумму и который изобрел свой алгоритм шифрования... потому что гостовский не особенно стойкий,... Хм... в чей продукт поверить?!...

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

Учитывая что вам нет необходимости передавать ключ (а это то как переставляются символы), то можно очень легко сделать абсолютно стойкую систему, весьма малыми затратами, главное чтобы кто-то случайно алгоритм перестановки не узнал%)

С чего такие выводы, прозорливый вы наш?

Тут еще вы все в кучу свалили, это печально. Начинающих сбиваете с толку. Цифровая подпись файла и гост стандарт для электронной цифровой подписи немного разные вещи. Такое ощущение, что не видите разницы. Я уж молчу про 99% мира, которого вы и не знаете.
Да еще и выдаете ваше желание-непонимание за якобы моё мнение, что цифровая подпись - это контрольная сумма. Да и ничего я не изобретал, писал же - использую не стандартный. Разочарую, но в криптографии нет терминов и понятия абсолютно невзламываемые шифры, для того применения о котором тут говориться.

Ваша беда что вы пишите это на основе ВАШЕГО личного понимания мира%))... У меня диплом специальность математика и диплом по криптографии)) так что я опираюсь на книги и накопленный опыт мира...

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

Электро́нная по́дпись (ЭП), Электро́нная цифровая по́дпись (ЭЦП) — информация в электронной форме, присоединенная к другой информации в электронной форме (электронный документ) или иным образом связанная с такой информацией. Используется для определения лица, подписавшего информацию (электронный документ).
По своему существу электронная подпись представляет собой реквизит электронного документа, позволяющий установить отсутствие искажения информации в электронном документе с момента формирования ЭП и проверить принадлежность подписи владельцу сертификата ключа ЭП. Значение реквизита получается в результате криптографического преобразования информации с использованием закрытого ключа ЭП.

Определить лицо, проверить принадлежность владельцу, на то она и подпись!

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

Вы делаете оценку моего понимания мира не зная меня, уже забавно. Похоже эго зашкаливает, по существу в этой теме пока ничего не сказали. Ну а вы пишите не на основе ВАШЕГО личного понимания мира, тогда чьего?


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


Соответствующее признание. Начните знакомство об электронной подписи c хеш-функций. Затем DES, AES.

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

Заканчиваем обсуждать личности!
Модератор.

о как. а более подробно не осветите аспект?

Да ключом является то как переставлены байты.

ну к примеру


Есть последовательность байт
а1 а2 а3 а4 а5 а6 а7 а8...

мы решаем что 1 пришедший байт ставим на 3 позицию, второй пришедший на 1 позицию, 3 пришедший на 4 позицию, а 4 пришедший на 2 и так по кругу получаем послдеовательность
а2 а4 а1 а3 а6 а8 а5 а7 ....
в контроллере делаем тоже самое в обратном порядке, весь входной поток так обрабатываем, как видите алгоритмические и ресурсные затраты минимальны

перестановка группами по 4 дает 4! вариантов, то есть 24 вида кода, перестановка из Н дает Н! видов кода, и только 1 из этого множества ваш.
Причем прелесть в том что все комбинации равновероятны, и даже перебрав их все, невозможно выделить по каким либо признакам верную.

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

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

Желаю удачи всем способным слышать ...

Огромное спасибо всем за обсуждение!

Не ожидал, что тема вызовет столь бурный интерес..

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

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

Однако при попытке обновиться через штатный бутлоадер при стирании невозможно стереть не всю память..

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

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

За последние лет 10 не припомню случая, чтобы кто-то вскрыл мою криптованную программу. Хотя знаю, что это задача решаемая, но недешево. Поскольку есть детерминанта определяемая ограниченностью кода, состоящим из команд и данных, стартового адреса, размерами и длинами регистров и тп. Как тут советовали перестановочный метод, можно применять, но он больше подходит к читаемым текстам, инструкциям, а не к загружаемому коду программы. Использовать пустые коды, циклы, многие коды будут запускаться и работать, только делать фигню... и тп - ну---у совсем несерьёзно для ARM.

Всем привет. почитал тему, сейчас как раз занимаюсь написанием загрузчика, который по езернет будет обновлять прошивку. Если я все верно понимаю, выглядеть это будет так:
1) загрузчик стартует первым из 0x08000000
2) загрузчик снимает защиту с области памяти, необходимой для прошивки, стирает необходимые страницы флэш
3) принимает новый код, дешифровывая его на лету и записывая во флэш по кусочкам по 512 байт
4) после заливки последнего кусочка закрывает флэш установкой битов защиты.
с этим вроде все понятно, но есть вопросики:
1) изначально область загрузчика должна быть закрыта битами защиты, что бы его не могли считать средствами отладки и левой прогой во флэш. как называются эти биты в stm32f4 и можно ли их устанавливать не на всю флэш а на определенные области?
2) при снятии защиты с области памяти основной прошивки, не сотрется ли вся флэш, включая загрузчик?
3) stm32f4 умеет декриптить AES, DES алгоритмами, думаю их и заюзать. какой алгоритм лучше заюзать?
4) ну допустим контроллер я научу расшифровывать, вопрос чем и как (имеет ввиду на пк) предварительно зашифровать прошивку ?

Подпись дает бОльшую гарантию, чем CRC. А так как и она и шифрование основаны на одном и том же коде - то накладные расходы минимальны


Неуловимый Джо?


На самом деле за какую-то вполне разумную денежку можно считать программу из залоченного процессора. Дальше загрузчик дизасемблируется, из него выдирается алгоритм и ключи.

Другое дело, что часто за эти деньги дешевле написать программу с нуля и получить поддерживаемый код на ЯВУ, а не дизасм...



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

Детали стоит почитать в Flash programming manual для вашей модели процессора.


aes более новый и по идее более защищенный, чем DES. Возможно и более тормозной...


Напишешь программу для ПК. На каком-нить питоне скажем в стандартной библиотеке есть алгоритмы шифрования. Для С/С++ надо поискать библиотеку - их полно

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

У меня другой вопрос, неужели ваши прошивки действительно столь ценны, что их надо защищать такими силами? В приборе кроме прошивки есть еще куча всего, да туже 4 слойную плату под БГА корпуса фиг так просто скопируешь, а потом надо еще найти кучу микросхем, номиналы, и так далее... я не утверждаю, но мне кажется это параноя, по моему легче повторить прибор, чем его копировать, ведь это дает еще возможность модификаций и поддержки....

гараинтию чего? того, что код закриптован именно вами?

минимальны, но и смысл в них сомнительный
или вы думаете, что ключ к коду сломали, а подпись не получится?

С Ethernet есть свои особенности. В сотой серии это 107. В этой теме про сотые спрашивали. Есть несколько разных сценариев для старта загрузчика, например если есть битовый свободный порт, можно его опрашивать и стартовать. Подумайте над вариантом, если произошел сбой в процессе загрузки, в любом месте, или не совпала контрольная сумма, и тп то как откатиться назад к предыдущей прошивке. Кусочки можно и поменьше делать от 256 до 32.

Думаю, что не все понятно как писать абдейт под Ethernet. Например желательна внешняя память, поскольку в загрузчике иметь дубль TCP/IP стека под 40...60K как то избыточно и много для загрузчика. Затем абдейт можно делат как по UDP, так и по TCP, так и по HTTP. Лучший алгоритм крипт/декрипт-овки, это проверенный вам. Можно и другие использовать не только AES, DES. Программу загрузчика когда пишите, обычно на C/C++, тогда и крипт/декрипт пишите, да и по-тестить можете. Если пользовать уровень HTTP, то по мне - на Java, будет универсальнее.

Я усматриваю тут "подводный камень"
1. Если мы не завершили программирование и загрузчик еще не установил бит защиты от чтения - и сняли питание- программа у нас почти зашита, а бит защиты от чтения- нет.
2. встроенным загрузчиком кажется, можно стирать память постранично- это работает в случае установленного бита защиты от чтения?

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



Есть много вещей где схемотехника очень проста, все сигналы цифровые..
А потом, все равно все компоненты устанавливаются снаружи платы а не внутри

это заблуждение, познакомтесь сперва с ARM-ами.
... запускаемые коды, но работающие не правильно... могут выжечь порт, сделать неработающем устройство. Зачем это нужно?


[CENSORED] Прошивку закрывают от конкурентов примерно на "время жизни продкута" на рынке от полугода до пару-тройки лет.
Силы не такие уж чтобы и большие, но зато даром получить открытый код не просто. Да еще, ... и дизассемблирование кода ARMа может мало что дать, тут еще нужно понимать какой стиль в написании программы использовался. 4-8 слойку под БГА корпуса без особых проблем, под рентген, коих много на тест контроле сборочного пр-ва. Вы еще не знаете что китайцы творят! Копируют чипы брендов и улучшают параметры.
Повторить прибор можно, конкуренты так и делают с некоторым опозданием и затратами, изучая програмный код конкурента. Мир тут пёстр, каждому своё.

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

ага
После дешифровки надо как-то убедиться, что получен осмысленный результат. Шансы на то, что случайно совпадет CRC больше, чем подпись.


Нет, я так не думаю. Хотя ключи там другие, и если ключ именно ломали (а не дизасемблировали выдранный из проца загрузчик), то придется ломать еще раз

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

Что у вас за стеки такие? У меня bootloader с uip стеком весит 17кБ и при этом умеет отзываться по UDP, перепрошиваться по TCP, получать IP по DHCP и получать IP сервера по его имени от DNS.

Как читали ранее это главное, если загрузчик писан вами.

Я усматриваю тут "подводный камень"
1. Если мы не завершили программирование и загрузчик еще не установил бит защиты от чтения - и сняли питание- программа у нас почти зашита, а бит защиты от чтения- нет.
2. встроенным загрузчиком кажется, можно стирать память постранично- это работает в случае установленного бита защиты от чтения?

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






Есть много вещей где схемотехника очень проста, все сигналы цифровые..
А потом, все равно все компоненты устанавливаются снаружи платы а не внутри

[CENSORED]
Для общего развития: если устройство при попытке получить прошивку физически уничтожается (сгорает), мне кажется это наилучший из вариантов защиты. Я вот делал ренген 6 слойной под БГА, а вы?...

... по TFTP я не подписался, из-за отсутствия проверок, низкой надежности. Он же совсем маленький, ну ...для AVR может и подойдет,
ресурсов мало, но не для ARM.

... по TFTP я не подписался, из-за отсутствия проверок, низкой надежности. Он же совсем маленький, ну ...для AVR может и подойдет,
ресурсов мало, но не для ARM.



У вас могут быть проблемы. 1) Нужен всё время сервер, накладно. 2) Из-за проблем в инете ваше устройство может некоторое или все время находиться в режиме bootloader_а. 3) В это время оно не будет функционировать.
А вот моё выкачивает абдейт, не прекращая работу, и перешивается за короткое время, еще использую внешнюю память, LwIP, поскольку еще и WEB сервер нужен.


Нет, по другому, почитайте внимательнее об этой процедуре в Datasheet.
Вами писаный загрузчик под коде-протектом все время. Коде-протект можно стереть вместе со всей программой только. Запись во внутреннюю флешь происходит из вашего загрузчика. Защита от записи/чтения во флешь это другая отдельная процедура, с коде-протектом не связана!


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

Golikov A., Aner, предупреждаю обоих последний раз о недопустимости перехода на личности.
Модератор.

Народ, сорри за дурацкий вопрос - а чем вы далете исходный файлдля загрузчика (Перед криптованием)?
Я всегда пользовался hex2bin.exe, но на хексы от Кейла для стм32ф4 он ругается. Может он у меня посто старый (95г)?

Криптующая программа кушает прямо hex.
Возможно проблема в том, что программа расположена с адреса 0x0800xxxx и утилите не хватает памяти? Страшно даже представить размер .bin из такого .hex

srec-cat:
http://srecord.sourceforge.net/