[fk1 0]

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

 

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

 

Если потребитель может считать из памятьи код программы и расчитать и проверить MD5 хэш, например, то вопрос решается (вопрос как именно считать и возможные уязвимости см. ниже). Но есть принципиальная необходимость защиты от копирования для программы. Кроме того, потребитель не имеет возможности подключения программатора и т.п.

 

Допустим, программа может расчитывать самостоятельно MD5 и выдавать пользователю. Но, в таком случае, вредоносная программа может попросту выдавать MD5 от достоверной программы. Усложним. Пусть программа расчитывает MD5(RAND + ROM), где RAND -- случайное число задаваемое пользователем. И можно сделать web-сайт, например, который будет генерировать RAND и выполнять такой же расчёт. И пользователю останется только сверить числа. Не зная заранее RAND злоумышленник не может сохранить в памяти заранее расчитанный верный MD5. Нельзя расчитываать MD5(ROM + RAND), т.к. в последнем случае злоумышленник заранее сохранит MD5(ROM). И также как злоумышленник не может хранить какой-то более короткий хэш программы, также и web-сайт должен хранить в памяти все прошивки, что не очень хорошо, но терпимо. Можно ещё сказать, что MD5 в таком применении имеет известные уязвимости, но вместо MD5 можно применить HMAC на его базе и более стойкие хэши, это не принципиально.

 

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

 

Не должно иметься возможности увеличения объёма программы. Как этого достичь. Допустим, что неиспользуемая программная память будет занята (псевдо)случайными данными и они тоже будут учавствовать в расчёте MD5. Естесственно, эти данные не должны подвергаться сжатию (иначе можно сохранить в сжатом виде и возвращаемся на абзац назад). Тогда внесение изменений в программу будет затруднено, большие изменения внести станет практически невозможно. А небольшие, скорей, возможно, если программа в ROM хранится в виде машинного кода. Т.к. машинный код немного сжимается. Следующим этапом было бы хранение в ROM уже сжатой версии программы дополненной случайной последовательностью и исполнение распакованной версии из RAM. Тогда внести изменения ещё более сложно, но такой метод ограничен используемым микроконтроллером.

 

Пользователь, получается, должен проверить, что в изделии используется именно микроконтроллер с таким-то объёмом памяти и на основе заданного им числа RND выдаётся MD5, который соответствует тому, что выдаёт web-сайт (на котором хранятся копии всех версий прошивок и следовательно можно осуществить такие же вычисления). Практически, пользователю сложно проверить тип микроконтроллера. Производство может, например, использовать МК с в двое большей памятью и во второй половине будет место попросту для исправленной программы, а в первой будет оригинал для прохождения проверки MD5. Маркировка же на чип может быть нанесена другая, от того микроконтроллера от которого нужно. И пользователю сложно разбирать прибор для проверки.

 

Допустим теперь, что прибор кроме МК обладает начительным объёмом FLASH-памяти. Если содержимое FLASH памяти включить в расчёт MD5 то всё получается. Но очень легко заменить микросхемы памяти на такие же, но большего объёма и трудно пользователю это проверить.

 

Допустим, что пользователь проверяет маркировку микроконтроллера и используемой FLASH-памяти. Или, что проще, MK и FLASH выбраны такими, что в таких же корпусах не существует аналогов с большими объёмами памяти.

 

Но если часть FLASH памяти используется для хранения каких-либо меняющихся данных? Допустим даже, что их можно стереть во время проверки. Получается, часть FLASH не проверяется и там может, например, находиться оригинальная программа по которой и посчитается MD5, а в памяти микроконтроллера будет совсем другое.

 

Неужто тупик? Вопрос чисто теоретический. Понятно, что организационные меры... Кроме того, можно допустить, что изделие проходит через 2 этапа производства и каждый программирует свою половину памяти (чётные и нечётные биты, например) и таким образом трудно внести искажения в ПО.

 

Продолжу размышления. Число RAND может быть достаточно длинным, объёмом равным объёму неиспользуемой части внешней FLASH-памяти и чуть менее, чем всё ОЗУ. Тогда вредоносной программе попросту негде будет хранить оригинал и, получается, такой метод действенный. Разумеется RAND тоже не должно сжиматься. И, кроме того, число RAND должно передаваться в МК в обратном порядке, например, чтобы нельзя было посчитать MD5 без сохранения в памяти.

Изменено 23 марта, 2013 пользователем Frolov Kirill

[alx2 0]

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

ИМХО вопрос должен быть не "как проверить, что программа та", а "как быть уверенным, что программу не изменили".

 

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

 

То же, о чем Вы спрашиваете - ИМХО да, тупик.

 

Неужто тупик? Вопрос чисто теоретический. Понятно, что организационные меры... Кроме того, можно допустить, что изделие проходит через 2 этапа производства и каждый программирует свою половину памяти (чётные и нечётные биты, например) и таким образом трудно внести искажения в ПО.

Хм... Если производитель не доверяет даже своим собственным сотрудникам... тогда да, пожалуй, тупик. :) А представляете, что будет, если программист четных байт вступит в сговор с программистом нечетных? :)

[yes 5]

чтобы дистанциироваться от "устройство в опечатаной упаковке" или сжигаем ЖТАГ после программирования микроконтроллера и т.п. интересных тем

 

предлагаю дополнить:

файл программы для загрузки во FLASH пересылается по интернету

 

-----------------

 

в этом случае применяется цифровая подпись - обычно AES-128 поверх CRC

 

такая технология есть у ARM-а, называется TrustZone

 

у iMX-ов есть HAB (хай ашуранси бут)

 

и т.д.

 

обычно в микроконтроллерах эти технологии являются секретными и я мне не попадалась документация по ним, так как фирмы ее так просто не дают - то есть, хоть я iMX и использую, но без HAB-а

 

-----------------------

 

для "самодельной" реализации такого протокола нужно уметь прошить в микроконтроллер некий секретных бут и секретный ключ (например для AES-128) после этого нет проблемы пересылать программу и при прошивки ее этим бутом она декриптуется и проверяется CRC - совпало, значит программа из годного источника, то есть того, который знает ключ для кодирования

 

отдельный вопрос - как защитить ключ (и секьюрный бут) от считывания (или стирания) из микроконтроллера?

тут надо либо в каждом отдельном случае разбираться - вплоть до сжигания ЖТАГа

 

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

 

----------------

 

хорошо это документировано для ПЛИС, поддерживающих такую крипто-загрузку, и общая теория и (может неинтересно в данном контексте) конкретная реализация. лучше всего, по-моему у Lattice для ПЛИС XP2, но наверно и у Альтеры (там вообще хорошо доки пишут) и у Ксайлинса тоже есть.

 

 

[sasamy 9]

мне не попадалась документация по ним, так как фирмы ее так просто не дают - то есть, хоть я iMX и использую, но без HAB-а

 

для i.mx23/28 информация c пошаговыми интрукциями открыто лежит на сайте freescale.com, включая весь инструментарий для подготовки имиджей и прошивки ключей в OTP, для других процессоров тоже не встречал ничего похожего.

Изменено 26 марта, 2013 пользователем sasamy

[yes 5]

для i.mx23/28 информация c пошаговыми интрукциями открыто лежит на сайте freescale.com, включая весь инструментарий для подготовки имиджей и прошивки ключей в OTP, для других процессоров тоже не встречал ничего похожего.

 

спасибо,

у меня i.mx35, но посмотрю повнимательней.

в этой системе защита от левого фирмваря и копирования плат кетайцами опирается на ПЛИС с AES-128, но и HAB может пригодится

 

[sasamy 9]

для других процессоров тоже не встречал ничего похожего.

 

Встретил :)

http://cache.freescale.com/files/32bit/doc...note/AN4547.pdf

http://cache.freescale.com/files/32bit/doc...note/AN4581.pdf

 

 

[Aner 3]

Давно есть понятие электронной подписи как документа так и файла программы. Чтобы быть уверенным что не было подмены. Электронная подпись вычисляется с помощью хеш-функции. Все есть в инете. Оригинальный файл+подпись в виде хеш-функции (хеш либо внутри файла, либо отдельно) Обычно оригинальный файл в открытом виде. Но есть ещё вариант криптованной подписи, в различных вариантах. В закриптованной оригинал документа, программы не в открытом виде. Оригинал доступен после раскриптовки. Можно пользовать и то и другое по ситуации. Также есть госты.

[san822 2]

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

 

 

чтобы дистанциироваться от "устройство в опечатаной упаковке" или сжигаем ЖТАГ после программирования микроконтроллера и т.п. интересных тем

 

Устройство будет без возможности усовершенствования путем заливки официальной прошивки от производителя.

 

предлагаю дополнить:

файл программы для загрузки во FLASH пересылается по интернету

 

Тут всплывает отдельная история с проверкой подлинности сайта, с которого скачивается программа.

 

 

 

С относительно простыми устройствами и продвинутыми пользователями идеальная история может выглядеть так:

 

1) Человек покупает устройство, в довесок идет флешка с исходниками прошивки и компилятором;

 

2) Приходит домой, где ставит на "кристально чистый" (в смысле - без какого либо зловредного ПО типа троянов) компьютер компилятор, открывает исходники, визуально смотрит их и проверяет на подозрительные куски кода, после этого готовит из только что просмотренных исходников файл для прошивки и заливает его в устройство; Перед каждым ответственным использованием устройства эту процедуру повторять.

 

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

 

 

[Aner 3]

... С относительно простыми устройствами и продвинутыми пользователями идеальная история может выглядеть так:

1) Человек покупает устройство, в довесок идет флешка с исходниками прошивки и компилятором;

 

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

 

2) Приходит домой, где ставит на "кристально чистый" (в смысле - без какого либо зловредного ПО типа троянов) компьютер компилятор, открывает исходники, визуально смотрит их и проверяет на подозрительные куски кода, после этого готовит из только что просмотренных исходников файл для прошивки и заливает его в устройство; Перед каждым ответственным использованием устройства эту процедуру повторять.

 

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

 

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

Через пол-годика новый проц, новый функционал и всё.

[Aner 3]

.

[san822 2]

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

 

Во-первых, этот метод годится для устройств с небольшим объемом кода, что, кстати, не всегда означает их примитивность. Часть библиотек могут быть стандартными уже прошитытми в ROM при производстве (нечно подобное реализовано в Stellaris ARM Cortex-M3) или компилятор может содержать библиотеки под целевую платформу, как в MBED, например. Это значит, что проверять часть кода не придется при безусловном доверии к поставщику чипов и средств разработки.

 

А многие компиляторы и так бесплатные при малом объеме кода, тот же Keil, например.

 

 

 

[Aner 3]

1) C небольшим объемом кода ... это для начинающих или попробовать, не оч интересно.

2) Стандартные библиотеки уже прошитытми в ROM ... это не нужно, избыточно, съедает ресурс проца, потребляет лишнего. И если ошибка или модификация либы то что? С ARM такой подход дает большие ограничения на собственную прогу и ее отладку.

3) ... безусловное доверие к проге - это что-то типа дуршлака без дырок, ... насмешили.

4) ... бесплатные при малом объеме кода - это да, но ничего более менее потребного не напишешь в этом объеме, но это не главное. Если продукт комереский, то плати хоть за бит кода. Почитайте лицензии. Как думаете, почему многие в GNU подались?

[fk1 0]

Давно есть понятие электронной подписи как документа так и файла программы. Чтобы быть уверенным что не было подмены. Электронная подпись вычисляется с помощью хеш-функции. Все есть в инете. Оригинальный файл+подпись в виде хеш-функции (хеш либо внутри файла, либо отдельно) Обычно оригинальный файл в открытом виде. Но есть ещё вариант криптованной подписи, в различных вариантах. В закриптованной оригинал документа, программы не в открытом виде. Оригинал доступен после раскриптовки. Можно пользовать и то и другое по ситуации. Также есть госты.

 

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

 

 

[syoma 1]

Не сильно то, что ТС спрашивал, но по теме дискуссии. Вот вам пример - девайс - навигационная система от достаточно именитого производителя. http://haxor.fi/2012/10/how-the-firmware-u...oyota-touch-go/

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

[Aner 3]

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

Есть и такой чип для закрытия данных: AT88SC0104CA, ставите рядом с вашим чипом и вуа'ля.