Защита данных FPGA, Кто подскажет где почитать? Опции

[prom]

Интересуют книги/статьи и т.п. по обеспечению защиты прошивки ПЛИС. Буду очень признателен также за дополнительные комментарии. Насколько слышал краем уха для защиты используется дополнительный CPLD. Я в этих вопросах новичок, так что просьба ногами не пинать

Заранее спасибо

[Maksim]

Обычно в FPGA и CPLD зашивают полином (очень длинный), а внутри FPGA потоки от этих полинов сравниваются. Но этот метод "колется" очень хорошо при малом основании полинома.
Сейчас есть более интересные решения Actel выпустила ПЛИС с внутренней FLASH. Это позволяет например при каждом включении ПЛИС (если её поставить вместо CPLD) писать напрмиер счётчик во флэш, а FPGA будет сообшаться только скажем номер, из которого по известному закону она внутри будет вырабатывать константу которую будет загонять в полином.
т.е. если при каждом включении питания смотреть обмен между ними, то он будет всегда разный.
Но в принципе лучше поставить маленький микркоонтроллер который тоже умеет шить свою память, и который и будет фиксировать каждый раз включение выключения схемы.

[prom]

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

Неужели ни одна из компаний не заморачивалась по сабжу? Первое, что приходит в голову - внутри ПЛИС прописывается серийный номер, к которому привязывается все остальное. Ну вариантов может быть много...

Вопрос к корифеям, работающим в компаниях - как вы защищаете IP в ваших разработках? Неужели никак?

[makc]

Неужели ни одна из компаний не заморачивалась по сабжу? Первое, что приходит в голову - внутри ПЛИС прописывается серийный номер, к которому привязывается все остальное. Ну вариантов может быть много...

Ну почему же ничего не сделано. Есть Actel ProASIC, у которых можно поставить бит защиты от чтения прошивки и все. После этого конфигурацию ПЛИС "сдуть" не получится. У них эта технология называется FlashLock.

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

[Serega Doc]

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

А аккумулятор в BIOS тоже должен садится через несколько лет а я встречал потерю настроек даже на новых материнских платах.

Что произойдет если всетаки батарейка сядет и прошивка сотрется?
Как востанавливать устройство? Вести к производителю? Это не решение проблемы. Об этом должны заботится компании производители FPGA.

Скажите а что за технология у ALTERA - LogicLock?

Спасибо

[vetal]

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

[Hilter]

У Xilinx в новых сериях (начиная с Virtex II Pro помоему) защита основавается на шифровании прошивки (Triple DES) , ключ для расшифровки хранится в самой ПЛИС. при прошивке сама плис декодирует поток. Ключ считать нельзя. Таким образом даже если снять образ флеши или промки с прошивкой - в другую ПЛИС без ключа ее не зашьеш и не декомпилируеш . Минус технологии в необходимости внешней батарейки для потдержания памяти ключа.

[Uuftc]

У Xilinx в новых сериях (начиная с Virtex II Pro помоему)

С Virtex II есть такая фича

[Andy-P]

FPGA + (CPLD с битом защиты и полиномом), вполне достаточно, чтобы отбить охоту у желающих скопировать.

Окончательно вопрос решается:

1. StratixII – во внешней памяти хранится криптованная прошивка. При загрузке в FPGA она декриптуется ключом (128 бит, если не ошибаюсь), который в свою очередь непосредственно прошивается во внутреннюю флэш FPGA. Ключ, разумеется, считать нельзя. Конечно, StratixII - для серьезных проектов

2. Попроще – MAXII (от 240 до 2210 LCELL, внутренняя флэш с битом секретности)

Как-то я задавал такой вопрос на семинаре. Суть ответа примерно такова: не актуально!

[Igor_S]

Скажите а что за технология у ALTERA - LogicLock?

Спасибо 

Eto ne w temu - LogicLock pozwoljaet "zamorozitj" otrabotannyj fragment proekta w FPGA, i ne menjatj ego trassirowku pri wseh posledujushih kompiljacijah proekta

[Serega Doc]

Попроще – MAXII (от 240 до 2210 LCELL, внутренняя флэш с битом секретности)

А кто подскажет пределы стоимости MAX II

[Vitus]

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

[yes]

кстати с полиномом совет весьма вредный -
есть так называемая рекурентная процедура Берликемпа-Месси (вроде так), да и вообще можно самому догадаться (пусть менее элегантным способом), которая восстанавливает полином длинны N по потоку 2N. с линейными вычислительными затратами (то есть удлиннение полинома не приводит к усложнению декодирования)

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

[Maksim]

кстати с полиномом совет весьма вредный -
есть так называемая рекурентная процедура Берликемпа-Месси (вроде так), да и вообще можно самому догадаться (пусть менее элегантным способом), которая восстанавливает полином длинны N по потоку 2N. с линейными вычислительными затратами (то есть удлиннение полинома не приводит к усложнению декодирования)

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

А кто вам даст эти 2N? - если N~300 и сранение идёт по нескольким битам(которыми обмениваются микроконтроллер и FPGA), то как вы собираетесь востановить основание полинома? главное чтобы микрокнтроллер имел на каждое влючение питание новое значение на входе полинома, например,счётчик.

[Wyvern]

Есть один способ, правда он не относится к проблеме защиты данных, а скорее, к борьбе с неплательщиками и пиратами
Известно, что у ПЛИС фирмы Xilinx имеют так называемую шину с тремя состояниями(глобальную).
Далее:

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

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

Ник

[acex2]

кстати с полиномом совет весьма вредный -
есть так называемая рекурентная процедура Берликемпа-Месси (вроде так), да и вообще можно самому догадаться (пусть менее элегантным способом), которая восстанавливает полином длинны N по потоку 2N. с линейными вычислительными затратами (то есть удлиннение полинома не приводит к усложнению декодирования)

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

А кто вам даст эти 2N? - если N~300 и сранение идёт по нескольким битам(которыми обмениваются микроконтроллер и FPGA), то как вы собираетесь востановить основание полинома? главное чтобы микрокнтроллер имел на каждое влючение питание новое значение на входе полинома, например,счётчик.

Алгоритм Берлекэмпа-Месси использует 2*N, а не 2^N бит, поэтому для восстановления полинома с длиной 300 бит необходимо всего лишь 600 бит последовательности. Что касается идеи с обновлением значения полинома с каждым новым включением, то не стоит забывать, что последовательность генерируется обоими устройствами: FPGA и МК в данном случае. А вот как вы собираетесь обновлять начальное значение полинома в FPGA с каждым включением, не совсем понятно. Разве что прошивку патчить каждый раз или добавлять фазу загрузки начального значения в FPGA после включения. Но это неэффективно, да и не нужно. Потому что для криптографически-стойкого алгоритма генерации ПСП единственный способ ее повторить, это записать ее в память и потом повторять каждый раз при включении устройства, что физически невозможно - каждую секунду на частоте 1 Мгц будет генерироваться 1 млн. новых бит.

Что касается полиномов, то тут необходимо использовать нелинейные генераторы, например каскад Голлмана или схему Stop-and-Go. Вариант из алгоритма A5 с увеличенными длинами полиномов тоже подойдет. Все они легко реализуются в железе и взломать их практически невозможно при большой разрядности используемых полиномов - проще будет CPLD "расковырять" под микроскопом.

[Harbour]

Я использую полином как ключ к простому алгоритму (обычно rc4), которым шифруется тестовый запрос. Для проверки подлинности делаем посылку типа запрос-ответ. Правда придется раскошелится, например для rc4, на 258 байт.

[acex2]

Я использую полином как ключ к простому алгоритму (обычно rc4), которым шифруется тестовый запрос. Для проверки подлинности делаем посылку типа запрос-ответ. Правда придется раскошелится, например для rc4, на 258 байт.

А можно поподробнее, А то я себе что-то слабо представляют как это все работает в связке FPGA+uC. Кто генерирует тестовый запрос? На основании какой случайности этот запрос формируется? Как часто вы его посылаете?

[Maksim]

кстати с полиномом совет весьма вредный -
есть так называемая рекурентная процедура Берликемпа-Месси (вроде так), да и вообще можно самому догадаться (пусть менее элегантным способом), которая восстанавливает полином длинны N по потоку 2N. с линейными вычислительными затратами (то есть удлиннение полинома не приводит к усложнению декодирования)

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

А кто вам даст эти 2N? - если N~300 и сранение идёт по нескольким битам(которыми обмениваются микроконтроллер и FPGA), то как вы собираетесь востановить основание полинома? главное чтобы микрокнтроллер имел на каждое влючение питание новое значение на входе полинома, например,счётчик.

Алгоритм Берлекэмпа-Месси использует 2*N, а не 2^N бит, поэтому для восстановления полинома с длиной 300 бит необходимо всего лишь 600 бит последовательности. Что касается идеи с обновлением значения полинома с каждым новым включением, то не стоит забывать, что последовательность генерируется обоими устройствами: FPGA и МК в данном случае. А вот как вы собираетесь обновлять начальное значение полинома в FPGA с каждым включением, не совсем понятно. Разве что прошивку патчить каждый раз или добавлять фазу загрузки начального значения в FPGA после включения. Но это неэффективно, да и не нужно. Потому что для криптографически-стойкого алгоритма генерации ПСП единственный способ ее повторить, это записать ее в память и потом повторять каждый раз при включении устройства, что физически невозможно - каждую секунду на частоте 1 Мгц будет генерироваться 1 млн. новых бит.

Что касается полиномов, то тут необходимо использовать нелинейные генераторы, например каскад Голлмана или схему Stop-and-Go. Вариант из алгоритма A5 с увеличенными длинами полиномов тоже подойдет. Все они легко реализуются в железе и взломать их практически невозможно при большой разрядности используемых полиномов - проще будет CPLD "расковырять" под микроскопом.

Берётся два полинома - предположим, длинный и короткий.
Начальное заполнение полиномов берём от датчика случайных чисел.
На вход длинного полниома заводим выход короткого.
Микроконтроллер при включении питания сообщает в FPGA номер
первого включения N=1(). FPGA полученный номер складывает с какой-то
секретной константой и результат на вход короткого полнинома и прокрутить его
M-тактов (M должно быть больше основания полинома (М=20, крутим 25-30 тактов и т.д.)).
Потом крутим короткий полином и результат подаём на вход длинного полинома,
и тоже прокручиваем энное количество тактов.Микроконтроллер тоже самое проделывает у
себя внутри, после чего результат сообщает в FPGA (в явном виде, с переставленными
битами и т.д.). После каждого включения питания при такой системе выдаваемые ответы
микроконтроллером будут "стоять" не рядом(имеет ввиду следующее значение полинома),а
сбиваться случайным образом за счёт короткого полинома.
Но это так что первое пришло в голову, а лучше я согласен - если есть место
то зашить туда шифратор с ключом и сообщать FPGA секретную константу для запуска, котороая
будет шифроваться гамированием, например (синхропосылка+зашифрованная константа).

[eugene]

Конечно прошу прощения, но я так и не понял, почему же в FPGA в качестве мества для хранения конфигурации производители избрали SRAM а не FLASH Хотя кажется так просто.... Да и с шифрованием напрягаться не надо было бы... Просто и для меня это вопрос достаточно актуальный. Заказчики требуют переходить c CPLD на FPGA именно из соображений "упрятать" внутрь процессор. А тут такие напряги с "открытостью" прошивки

[Maksim]

Конечно прошу прощения, но я так и не понял, почему же в FPGA в качестве мества для хранения конфигурации производители избрали SRAM а не FLASH Хотя кажется так просто.... Да и с шифрованием напрягаться не надо было бы... Просто и для меня это вопрос достаточно актуальный. Заказчики требуют переходить c CPLD на FPGA именно из соображений "упрятать" внутрь процессор. А тут такие напряги с "открытостью" прошивки

Технологические трудности. Посмотрите Actel ведь у них нет таких больших кристаллов как у Xilinx, Altera, а это уже о чём-то говорит. Может кто более сведущий в технологии обяснить более подробно.

[acex2]

Берётся два полинома - предположим, длинный и короткий.
Начальное заполнение полиномов берём от датчика случайных чисел.
На вход длинного полниома заводим выход короткого.
Микроконтроллер при включении питания сообщает в FPGA номер
первого включения N=1(). FPGA полученный номер складывает с какой-то
секретной константой и результат на вход короткого полнинома и прокрутить его
M-тактов (M должно быть больше основания полинома (М=20, крутим 25-30 тактов и т.д.)).
Потом крутим короткий полином и результат подаём на вход длинного полинома, и тоже прокручиваем энное количество тактов.Микроконтроллер тоже самое проделывает у себя внутри, после чего результат сообщает в FPGA (в явном виде, с переставленными битами и т.д.). После каждого включения питания при такой системе выдаваемые ответы микроконтроллером будут "стоять" не рядом(имеет ввиду следующее значение полинома),а сбиваться случайным образом за счёт короткого полинома.
Но это так что первое пришло в голову, а лучше я согласен - если есть место то зашить туда шифратор с ключом и сообщать FPGA секретную константу для запуска, котороая будет шифроваться гамированием, например (синхропосылка+зашифрованная константа).

А чем не устраивают два синхронных нелинейных генератора на LFSR: один в CPLD, другой в FPGA? CPLD шлет выходную последовательность в FPGA по одной линии , в FPGA стоит простой XOR (с триггером на выходе во избежании глитчей) от двух последовательностей. Как только последовательности не совпали - происходит Reset (общий, или какого-нибудь локального автомата для скрытности). В итоге имеем простейшую схему внутри FPGA на нескольких SRL16 + пару LUT для проверки и организации нелинейности + только один дополнительный внешний пин.

Что касается посылок с шифрованием, то тут придется потрудиться над созданием генератора случайных чисел именно в FPGA, который после каждого ресета смог бы генерировать новое случайное число. Иначе можно будет один раз записать посылку от внешнего микроконтроллера со всеми "синхропосылками и гаммами" и затем просто ее тупо повторять при каждом перезапуске. И пусть там хоть 256-битный AES внутри FPGA - не поможет.

[Maksim]

[quote=acex2,Feb 22 2005, 01:28]
А чем не устраивают два синхронных нелинейных генератора на LFSR: один в CPLD, другой в FPGA? CPLD шлет выходную последовательность в FPGA по одной линии , в FPGA стоит простой XOR (с триггером на выходе во избежании глитчей) от двух последовательностей. Как только последовательности не совпали - происходит Reset (общий, или какого-нибудь локального автомата для скрытности). В итоге имеем простейшую схему внутри FPGA на нескольких SRL16 + пару LUT для проверки и организации нелинейности + только один дополнительный внешний пин.
[/quote]
А за счёт чего нелинейность Чего-то я не понял

Что касается посылок с шифрованием, то тут придется потрудиться над созданием генератора случайных чисел именно в FPGA, который после каждого ресета смог бы генерировать новое случайное число. Иначе можно будет один раз записать посылку от внешнего микроконтроллера со всеми "синхропосылками и гаммами" и затем просто ее тупо повторять при каждом перезапуске. И пусть там хоть 256-битный AES внутри FPGA - не поможет.

[/quote]
С шифрованием есть конечно проблемы.

[acex2]

А за счёт чего нелинейность Чего-то я не понял

Я же писал чуть выше - LFSR лишь конструктивный блок. Для внесения нелинейности берется несколько LFSR и соединяются по нелинейной схеме. Самих схем очень много - они широко используются в потоковых криптосистемах. Я тут не поленился и нарисовал схему Stop-and-Go и упрощенный каскад Голлмана с 3-мя LFSR. Длины LFSR стоит выбирать разные и достаточно большие. Стандартное правило: сумма длин двух наименьших LFSR можно условно рассматривать с точки зрения brute-force взлома, как длину ключа в обычной блочной криптосистеме.

Эскизы прикрепленных изображений

 

[Harbour]

Я использую полином как ключ к простому алгоритму (обычно rc4), которым шифруется тестовый запрос. Для проверки подлинности делаем посылку типа запрос-ответ. Правда придется раскошелится, например для rc4, на 258 байт.

А можно поподробнее, А то я себе что-то слабо представляют как это все работает в связке FPGA+uC. Кто генерирует тестовый запрос? На основании какой случайности этот запрос формируется? Как часто вы его посылаете?

Народ отклонился от темы, мое IMHO :

1. В простом случае SRAM-based FPGA защитить (кроме имеющих внутренниий ключ Stratix-II и им подобные) невозможно, т.к. тупо можно повторить битовый поток конфигурации. Посему имеет смысл ставить мелкую CPLD/FPGA или uC с битами защиты, в которых реализуется _часть_ основной логики.
2. Flash-based FPGA защищать смысла не имеет - остается уповать на крепость бита защиты.
3. Другое дело - когда необходимо защитить свои изделия от попыток "некорректного" применения - то бишь необходимо гарантировать работу своих изделий только со своими - вот тут есть небольшой простор, о чем собственно, и был мой пост. Пока сделал просто :
- взял atmega8515, реализовал в нем 2 64-битные M-последовательности и rc4, одна M1 используется как отсчетная, вторая M2 используется как псевдо-ГСЧ
- все это ставится в двух девайсах, которые связаны какой-нить линкой
- периодически девайсы выбирают из M2 какой-нить "случайный" кусок, из M1 кусок и его индекс (тоже "случайный"), из куска M1 делаем rc4 ключ, шифруем этим ключом кусок M2 и посылаем той стороне индекс от M1 и данный зашифрованный кусок - та сторона сравнивает и делает соответствующие выводы

При небольшом усилии можно конечно все слегка наворотить - но мое изделие такой крутой защиты не требует (плата в розницу стоит порядка $100)

P.S. "Случайный" взято в кавычки так как генератор ентропии, который сделан в avr - весьма простенький - собирает там инфу внутри cpu, и т.д.

[acex2]

1. В простом случае SRAM-based FPGA защитить (кроме имеющих внутренниий ключ Stratix-II и им подобные) невозможно, т.к. тупо можно повторить битовый поток конфигурации. Посему имеет смысл ставить мелкую CPLD/FPGA или uC с битами защиты, в которых реализуется _часть_ основной логики.

Основную логику в FPGA практически всегда приходится "вылизывать", сражаясь за каждый мегагерц. И вынесение части логики во внешний CPLD, а уж тем более uC, этому ну никак не помогает. Поэтому остается только _вспомогательная_ логика.

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

[Maksim]

А за счёт чего нелинейность Чего-то я не понял

Я же писал чуть выше - LFSR лишь конструктивный блок. Для внесения нелинейности берется несколько LFSR и соединяются по нелинейной схеме. Самих схем очень много - они широко используются в потоковых криптосистемах. Я тут не поленился и нарисовал схему Stop-and-Go и упрощенный каскад Голлмана с 3-мя LFSR. Длины LFSR стоит выбирать разные и достаточно большие. Стандартное правило: сумма длин двух наименьших LFSR можно условно рассматривать с точки зрения brute-force взлома, как длину ключа в обычной блочной криптосистеме.

Теперь понятно.
Как говорится теже яйца только в профиль

[Андрей Харитонов]

я думаю так
если ценность вашей FPGA прошивки сравнима со стоимостью нового истребителя то не поможет ничего, т.к. все ваши дополнительные навешанные компоненты легко прочтуться даже с битами защиты специализирующимися на этом фирмами (чтение закрытого проца 1-5 тысяч $, закрытой CPLD 1-10 тысяч $). В этом случае можно говорить только о степени затруднения копирования проекта - поставить пару редко используемых в разработках процессоров разных производителей втом числе например наш КР1878ВЕ1, парочку CPLD опять таки разных производителей, наплевать на мучения покупателя товара по истечении гарантийного срока и поставить батарейку, на проци водрузить шифрованный обмен, в CPLD можно вынести жизненно важные куски схемы - и все равно стоимость истребителя перевесит (не поможет и батарейка). А уж если в копировании заинтересована американская сторона, да еще и вся элементная база у вас американская - вообще труба (у них на всех процах и плисах закладки стоят - че хочешь сделают и прошивку сдерут и из строя выведут, только что танцевать плисину не заставят, а на серьезном софте компиляторы в прошивку доп информацию с зашифрованным исходным кодом включают, так что и проблем с декомпиляцией особо не будет).

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

[makc]

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

А можно узнать, откуда вышеприведенная информация? Ссылочку?

[acex2]

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

А можно узнать, откуда вышеприведенная информация? Ссылочку?

Это, похоже, из разряда детских страшилок. Хотя, кто его знает - может Винда такая большая, потому что идет с зашифрованным исходным кодом?

[makc]

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

А можно узнать, откуда вышеприведенная информация? Ссылочку?

Это, похоже, из разряда детских страшилок. Хотя, кто его знает - может Винда такая большая, потому что идет с зашифрованным исходным кодом?

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

[myq]

Предлагается такой вариант реализации:

Во внешней FLASH хранится зашифрованная прошивка. CPLD - расшифровывает прошивку и посылает ее в FPGA. Секретный ключ шифрования хранится в защищенной прошивке CPLD.
Поскольку в CPLD ресурсов не так много, то полноценное шифрование (типа ГОСТ 28147-89) реализовать не удастся. Можно сократить число раундов, или использовать более простое поточное шифрование.

Одна контора таким образом защитила прошивку, которая составляет гостайну.

[NeoN]

... на стыке CPLD-FPGA ставится логический анализатор, который благополучно запоминает декодированную прошивку в процессе конфигурирования FPGA. Детский сад
ИМХО, единственное верное средство "антистыринга" - перенос части функций в CPLD либо FLASH based FPGA. Штучки типа "генератор ПСП в CPLD и сравнивалка в FPGA, не совпало - reprog" потенциально не надежны из-за возможных сбоев по клокам и рассинхронизации генераторов.

[fake]

Во внешней FLASH хранится зашифрованная прошивка. CPLD - расшифровывает прошивку и посылает ее в FPGA. Секретный ключ  шифрования хранится в защищенной прошивке CPLD.
Поскольку в CPLD ресурсов не так много, то полноценное шифрование (типа ГОСТ 28147-89) реализовать не удастся. Можно сократить число раундов, или использовать более простое поточное шифрование.

А что мешает использовать новые Virtex-ы, шифруя прошивку DES-ом предусмотренным в ISE методом ?

[makc]

Во внешней FLASH хранится зашифрованная прошивка. CPLD - расшифровывает прошивку и посылает ее в FPGA. Секретный ключ  шифрования хранится в защищенной прошивке CPLD.
Поскольку в CPLD ресурсов не так много, то полноценное шифрование (типа ГОСТ 28147-89) реализовать не удастся. Можно сократить число раундов, или использовать более простое поточное шифрование.

А что мешает использовать новые Virtex-ы, шифруя прошивку DES-ом предусмотренным в ISE методом ?

А если используется Spartan 2,3 или вообще не Xilinx? К тому же DES - это явно не самый современный алгоритм для защиты данных и совершенно неизвестно, как он там реализован.

[acex2]

Во внешней FLASH хранится зашифрованная прошивка. CPLD - расшифровывает прошивку и посылает ее в FPGA. Секретный ключ  шифрования хранится в защищенной прошивке CPLD.
Поскольку в CPLD ресурсов не так много, то полноценное шифрование (типа ГОСТ 28147-89) реализовать не удастся. Можно сократить число раундов, или использовать более простое поточное шифрование.

А что мешает использовать новые Virtex-ы, шифруя прошивку DES-ом предусмотренным в ISE методом ?

Похоже, не доверяет у нас народ устройствам с батарейками. Даже несмотря на заявленный срок работы в 10+ лет.

[bbg]

К тому же DES - это явно не самый современный алгоритм для защиты данных и совершенно неизвестно, как он там реализован.

Там вроде 3DES..

[acex2]

А если используется Spartan 2,3 или вообще не Xilinx? К тому же DES - это явно не самый современный алгоритм для защиты данных и совершенно неизвестно, как он там реализован.

В Virtex2 используется 3DES, а не DES. А в Virtex4 AES.

[yes]

2 mvq - лажа какая-то с гостайной

что мешает в этой схеме подключится к конфигурационным входам FPGA (я не первый, кто это заметил, просто дальше хочу вставить "мораль")

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

[myq]

2yes
ну еще начнем с того, что они не продают свое изделие всем подряд. там завязки с ФСБ, речь не об этом.

(+ 2NeoN)Как ни крути, подключившись к конфигурационным ногам можно ВСЕГДА СЛИТЬ ЛЮБУЮ ПРОШИВКУ, совершенно неважно, что и чем шифруешь.

2acex2
2bbg
2fake
- какая разница, что там DES или AES. А где по вашему секретный ключ:
1) в САПРЕ и в ПЛИСе аппааратно зашит и не меняется
2) передается вместе с прошивкой ))
Ну и чего это за защита тогда??? *****, а не защита.

p.s.
тогда уж к слову.
использование CPLD тоже не гарантирует секретность прошивки (прошивки CPLD).

Сообщение отредактировал Nixon - Mar 31 2005, 12:37

[acex2]

2yes
ну еще начнем с того, что они не продают свое изделие всем подряд. там завязки с ФСБ, речь не об этом.

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

2acex2
2bbg
2fake
- какая разница, что там DES или AES. А где по вашему секретный ключ:
1) в САПРЕ и в ПЛИСе аппааратно зашит и не меняется
2) передается вместе с прошивкой ))
Ну и чего это за защита тогда??? *****, а не защита.

Ключи легко меняются, так как хранятся во внутренней RAM - для этого и нужна внешняя батарейка, чтобы они не пропали при отсутствии питания платы. Считать обратно из этой RAM ключи нельзя - только записать новые. Bit-файл прошивки шифруется после синтеза/разводки и записывается во внешнее EEPROM/Flash. При включении питания грузится в зашифрованном виде в FPGA и там расшифровывается. Какие здесь слабые места?

[myq]

Ключи легко меняются, так как хранятся во внутренней RAM - для этого и нужна внешняя батарейка, чтобы они не пропали при отсутствии питания платы. Считать обратно из этой RAM ключи нельзя - только записать новые. Bit-файл прошивки шифруется после синтеза/разводки и записывается во внешнее EEPROM/Flash. При включении питания грузится в зашифрованном виде в FPGA и там расшифровывается. Какие здесь слабые места?

Те, о ком я упомянул, сделали это на Altere, а не на Xilinx-e.

К тому же у меня вопрос - как fpga расшифрует прошивку, если прошивки в ней еще никакой нет? (с xilinx знаком в большей степени теоретически, а отличие от altera)

[_Sam_]

Осложнить жизнь жаждущим вашу прошивку можно, используя ПЛИС и флэш в BGA корпусах.

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

[acex2]

2myq:

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

2_Sam_:

Так как алгоритм программирования известен, то прошивка из Flash легко снимается через JTAG, обычно выведенный на платах с FPGA (тем более в BGA корпусах).

[Андрей Харитонов]

ну можете начать с www.semiresearch.com, www.microcode.ru немножко усилий и сами найдете еще десятки контор. Некоторые занимаются поджариванием, облучением, растворением в кислоте, микроскопированием и прочим рукоблудием, некоторые коммерческим использованием закладок в процессорах (Flash Pic Reader например для всеми любимых американских пиков ). если поусердствуйте, то найдете и способы чтения некоторых процев в домашних условиях.
по поводу секретиков винды начните знакомство с программ encase, ilook, ftk для начала, когда начнете вспоминать про детские страшилки, полазте по сайтам вирусописателей - там секретиков еще больше ну и т.д.
а про необъяснимые отключения связи в целых регионах в разгар некоторых наших военных компаний тоже не слышали? ладно пусть это будут детские страшилки, вспомните про них когда нибудь. Может вам страшилок myq подкинет - он тут громкие названия из трех букв пишет
а вообще Neon прав - одна дружественная myqу контора могла бы еще более усилить защиту проекта, выкинув дорогую CPLD и прилепив на FPGAшку более дешевую бумажку с надписью "гостайна" и еще три магические буквы.
а продавать только в контору это конечно хорошо, сразу Калугин вспоминается

[acex2]

Вот и я говорю - страшилки! Причем детские. Потому что вместо ссылок по поводу "у них на всех процах и плисах закладки стоят - че хочешь сделают и прошивку сдерут и из строя выведут, только что танцевать плисину не заставят, а на серьезном софте компиляторы в прошивку доп информацию с зашифрованным исходным кодом включают, так что и проблем с декомпиляцией особо не будет" только общие фразы и "притянутые за уши" программы для анализа логов, кукисов и удаленных файлов. Что касается semiresearch.com и др., то если бы они использовали заведомо установленные производителями чипов закладки, то не требовали бы несколько копий чипа для взлома.

[Андрей Харитонов]

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

[Андрей Харитонов]

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

[3.14]

Я просто не понял почму содержимое FPGA при этом нельзя через JTAG прочитать?

[acex2]

Я просто не понял почму содержимое FPGA при этом нельзя через JTAG прочитать?

А вы поставьте FPGA в BGA корпусе и TDO на разъем не выводите

[3.14]

Итак, повтоюсь.

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

Способы защиты содержимого FPGA:
1) Использование семейств ПЛИС, в которых предусмотрена защита содержимого.
Достоинства:
Наивысшая степень защиты содержимого.
Недостатки:
(возможная) Смена производителя (среды разработки), большая стоимость.
2) Питание ядра всегда поддерживать (батарея, аккамулятор), ограничить доступ до JTAG пинов (использовать BGA или откусывать пины).
Достоинства:
Степень защиты близка к п.1.
Недостатки:
А вы сможете обеспечить такое питание?
3) Не закрывать прошивку FPGA, использовать внешнее "закрытое" устройство либо как часть проекта. либо как генератор ПСП, на основании работы которого принимать решение.
3.1) В качестве внешнего устройства использовать CPLD.
3.2) В качестве внешнего устройства использовать микроконтроллер.
У третьего метода возможна тьма вариантов, но в любом случае, они сводятся к тому, что в FPGA входит N линий, а выходит M линий. Если предположить что имеем ПСП которую "невозможно" вычислить, все равно, можно записать состояние этих линий. Нужно учитывать объем данных передаваемых через эти линии, следить за тем чтоб он не был слишком маленький.
Достоинства:
Можно применить к любой FPGA.
Недостатки:
Меньшая степень защиты, время на разработку "закрывашки".

Кто что добавит, исправит?

[makc]

Итак, повтоюсь.

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

Способы защиты содержимого FPGA:

[skipped]

2) Питание ядра всегда поддерживать (батарея, аккамулятор), ограничить доступ до JTAG пинов (использовать BGA или откусывать пины).
  Достоинства:
    Степень защиты близка к п.1.
  Недостатки:
    А вы сможете обеспечить такое питание?

[skipped]

Кто что добавит, исправит?

Хочу добавить, что для этого способа возможно ограничение доступа к JTAG-принам при задании конфигурации некоторых видов ПЛИС. Так для Spartan 2 в опциях конфигурации пошивки есть возможность запретить Readback and Reconfiguration. (Хотя об этом в даташите ничего не написано).

[Андрей Харитонов]

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

Возможно конечно идея не выдержит критики

[3.14]

2 Андрей Харитонов
А как Вы себе представляете подмену блока?
Нужный блок, может быть распылен по всему битстрейму.
Скорее всего все сведется к огромному количеству битстреймов, исходя из вариантов нужных/ненужных блоков.

[Андрей Харитонов]

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

[3.14]

2 Андрей Харитонов

1. Вариант относится к категории 2.1
2. Если хотите его утвердить как имеющим шансы на существование, то укажите алгоритм "выделения" блока.

[Vitus]

Под №1 все-таки следует назвать (С)!

[FAE]

Используйте ACTEL !!! Там этой проблемы вообще не возникает, т.к. ПЛИС не требуется загружать каждый раз при включении питания, и , таким образом, нельзя перехватить поток данных. (www.actel.com)

[des00]

Используйте ACTEL !!! Там этой проблемы вообще не возникает, т.к. ПЛИС не требуется загружать каждый раз при включении питания, и , таким образом, нельзя перехватить поток данных.  (www.actel.com)

Это то можно, но архитектура этих плис не совсем подходит для некоторых задач ((

[alexr22b]

Очень скоро Xilinx выпустит Spartan 3 с внутренним флашем. Будет на $.70 дороже обичного в серии. Да и lattice уже имеет fpga's с встроенным флашем

[makc]

Очень скоро Xilinx выпустит Spartan 3 с внутренним флашем. Будет на $.70 дороже обичного в серии. Да и lattice уже имеет fpga's с встроенным флашем

А откуда такая информация? Можно ссылочку?

[alexr22b]

Очень скоро Xilinx выпустит Spartan 3 с внутренним флашем. Будет на $.70 дороже обичного в серии. Да и lattice уже имеет fpga's с встроенным флашем

А откуда такая информация? Можно ссылочку?

Информация от xilinx rep. ссылочки нету потому как рано еше

[BSV]

А зачем держать под батарейкой ПЛИС? Если необходимо защитить не плату, а устройство (в корпусе), то достаточно питать лишь FLASH и стереть ее при попытке вскрытия/включения без корпуса.

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

Промелькнула еще здравая идея с частичным перепрограммированием ПЛИС, хотя непонятно, как это использовать (может ли ПЛИС программировать сама себя без участия внешних ног, например, через JTAG?).

Хотя, если подумать, даже если FLASH будет внутри корпуса, наверняка найдутся методы, как оттуда отковырять прошивку, все дело лишь в цене!

[Shread]

Защитить содержимое FPGA от потокового считывания, при ее начальной инициализации, практически нереально(не считая батарейки), соответственно остается, одно-необходимо сделать так, чтоб считывание собственно самой прошивки не принесло ничего хорошего, т.е нужно использовать внешний мк, с возможностью защиты от копирования. Методов защитить свзяку FPGA+мк достаточно, тут, как и в в сигнализациях для авто, важно чтоб взломщик поменьше знал о том, как может быть защищена данная связка. Побольше разнообразия

Промелькнула еще здравая идея с частичным перепрограммированием ПЛИС, хотя непонятно, как это использовать (может ли ПЛИС программировать сама себя без участия внешних ног, например, через JTAG?).

Хотя, если подумать, даже если FLASH будет внутри корпуса, наверняка найдутся методы, как оттуда отковырять прошивку, все дело лишь в цене!

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

[kas]

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

И еще, тут, по моему неучли человеческий фактор. Криптостойкость, скорее всего, будет расти. И очень скоро окажется что человека "сломать" окажется проще/дешевле.

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

[makc]

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

Не могли бы Вы рассказать по-подробнее, каким образом реализуется возможность доконфигурации ПЛИС?

[Shread]

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

[kas]

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

Не могли бы Вы рассказать по-подробнее, каким образом реализуется возможность доконфигурации ПЛИС?

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

[des00]

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

Не могли бы Вы рассказать по-подробнее, каким образом реализуется возможность доконфигурации ПЛИС?

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

а можно поподробнее ?? какова длина полинома, кол-во данных для его смены и т.д.? И ИМХО это те же яйца, только сбоку "Осталось только защитить обмен между ПЛИС и другим управляющим устройством" - чем это отличаеться от "осталось защитить обмен между конф. микросхемой и ПЛИС" ?

[kas]

"Осталось только защитить обмен между ПЛИС и другим управляющим устройством" - чем это отличаеться от "осталось защитить обмен между конф. микросхемой и ПЛИС" ?

ИМХО. Не совсем. В данном случае можно организовать шифрование/дешифрование информации уже с участием самой ПЛИС как готового устройства, а не конфигурируемого.

В случае обмена между ПЛИС и конф. микросхемой структура данных и контакты известны.

А в моем случае надо знать структуру управляющих кадров/контактов. Сложность получения этих данных многократно выше сложности получения "прошивки" ПЛИС.

[des00]

ИМХО. Не совсем. В данном случае можно организовать шифрование/дешифрование информации уже с участием самой ПЛИС как готового устройства, а не конфигурируемого.

Хмм а вот здесь можно поподробнее ?? Какий именно алгоритм и с какой длинной ключа вы собираетесь пользовать ? А прикидывали ли вы во что это выльеться ?

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

Хмм может мы спорим о разных вещах, но если меня будет интеросовать копирование именно вашего устройства, то я солью прошивку вашей фпга и коды управления фпга., именно с этой прошивкой. И какая мне разница чем они закодированны и какой формат они имеют.
Или вы имеете в виду накинуть на все это еще и алгоритм динамической смены ключа ?? то собираетесь ли вы менять весь ключ ? как вы синхронизируете смену ключа в ФПГА и МК и т.д. ?

[makc]

"Осталось только защитить обмен между ПЛИС и другим управляющим устройством" - чем это отличаеться от "осталось защитить обмен между конф. микросхемой и ПЛИС" ?

ИМХО. Не совсем. В данном случае можно организовать шифрование/дешифрование информации уже с участием самой ПЛИС как готового устройства, а не конфигурируемого.

В случае обмена между ПЛИС и конф. микросхемой структура данных и контакты известны.

А в моем случае надо знать структуру управляющих кадров/контактов. Сложность получения этих данных многократно выше сложности получения "прошивки" ПЛИС.

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

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

[kas]

Хмм может мы спорим о разных вещах, но если меня будет интеросовать копирование именно вашего устройства, то я солью прошивку вашей фпга и коды управления фпга., именно с этой прошивкой. И какая мне разница чем они закодированны и какой формат они имеют.
Или вы имеете в виду накинуть на все это еще и алгоритм динамической смены ключа ?? то собираетесь ли вы менять весь ключ ? как вы синхронизируете смену ключа в ФПГА и МК и т.д. ?

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

[des00]

Хмм может мы спорим о разных вещах, но если меня будет интеросовать копирование именно вашего устройства, то я солью прошивку вашей фпга и коды управления фпга., именно с этой прошивкой. И какая мне разница чем они закодированны и какой формат они имеют.
Или вы имеете в виду накинуть на все это еще и алгоритм динамической смены ключа ?? то собираетесь ли вы менять весь ключ ? как вы синхронизируете смену ключа в ФПГА и МК и т.д. ?

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

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

[kas]

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

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

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

[des00]

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

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

хмм вопрос стоял " Защита данных FPGA. ...". Я конечно понимаю что это входит во множество "защита интелектуальной собственности", но тем не менее согласитесь что это разные вещи.
Вам удалось защитить свою систему как говориться "от дурака", т.е. от грубого, не интелектуального копирования,причем ценой не нужного усложнения и использования ресурсов ПЛИС и МК. (почему я уже говорил).
Начет заливки платы чем нибудь - это пройденый этап, не работает.

А насчет цен так давно известно что основное правило взлома :
"Стоимость взлома информации должна быть много меньше стоимости самой информации " , иначе это не имеет комерческого смысла
)

[kas]

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

Вы считаете что можно защитить систему без усложнения программной и/или аппаратной части?

[des00]

Вы считаете что можно защитить систему без усложнения программной и/или аппаратной части?

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

[kas]

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

ИМХО. Ничего сложного в этой защите нет, и аппаратные ресурсы потрачены не зря. В добавок ко всему я получил достаточно гибкую систему (что являлось одним из требований ТЗ).

[Андрей Харитонов]

если я правильно понял, то kas просто рассказал нам как он реализовал метод 3.2

3) Не закрывать прошивку FPGA, использовать внешнее "закрытое" устройство либо как часть проекта. либо как генератор ПСП, на основании работы которого принимать решение.
3.1) В качестве внешнего устройства использовать CPLD.
3.2) В качестве внешнего устройства использовать микроконтроллер.

по преложенной ранее 3.14 классификации
и естественно ни о какой "доконфигурации" здесь речи быть не может.

[Guest_Pruga_*]

Насущная потребность заставила меня поднять из под спуда эту тему. А тема актуальна и по сей день. Постановка задачи остается той же: необходимо обеспечить защиту прошивки ПЛИС, желательно более простыми методами. Немного поискав на сайте Xilinx'а обнаружил следующий документ: http://direct.xilinx.com/bvdocs/appnotes/xapp780.pdf

В документе описан способ защиты от копирования с использованием внешней EEPROM памяти, в которой хранится секретный ключ. Если говорить кратко то суть способа в следующем: на стадии разработки проекта в EEPROM записывается 64-бит секретный ключ, который считать обратно невозможно. В проект на FPGA добавляется некоторое устройство (IFF), которое хранит такой же ключ. После загрузки по открытому каналу, открытой прошивки в FPGA, IFF посылает некторую случ. послед. в EEPROM и шифрует ее же на секретном ключе (который зашивается вместе с прошивкой). EEPROM также шифрует принятую послед. на том же секретном ключе (используется алгоритм SHA-1) и возвращает обратно. IFF сравнивает полученную от EEPROM последовательность с вычисленной ранее, если они сходятся - выдает сигнал глобального разрешения работы проекта.
Примеры кода на VHDL для такого способа организации защиты также приводятся. http://www.xilinx.com/bvdocs/appnotes/xapp780.zip

Итак в качетсве дополнительного ресурса для защиты используется одна микросхема с возможностью шифровки данных (в очень миниатюрном корпусе - 2 вывода) и некоторый ресурс FPGA (100 Slices+1кб блочной памяти+1пин). Остается только оценить степень защищенности такого способа. Сможет ли гипотетический РЭинженер перехватив зашифрованную послед. расшифровать ключ?? Или подключив логический анализатор и перехватив конфигурационную прошивку извлечь ключ оттуда??

[Maksim]

Насущная потребность заставила меня поднять из под спуда эту тему. А тема актуальна и по сей день. Постановка задачи остается той же: необходимо обеспечить защиту прошивки ПЛИС, желательно более простыми методами. Немного поискав на сайте Xilinx'а обнаружил следующий документ: http://direct.xilinx.com/bvdocs/appnotes/xapp780.pdf

В документе описан способ защиты от копирования с использованием внешней EEPROM памяти, в которой хранится секретный ключ. Если говорить кратко то суть способа в следующем: на стадии разработки проекта в EEPROM записывается 64-бит секретный ключ, который считать обратно невозможно. В проект на FPGA добавляется некоторое устройство (IFF), которое хранит такой же ключ. После загрузки по открытому каналу, открытой прошивки в FPGA, IFF посылает некторую случ. послед. в EEPROM и шифрует ее же на секретном ключе (который зашивается вместе с прошивкой). EEPROM также шифрует принятую послед. на том же секретном ключе (используется алгоритм SHA-1) и возвращает обратно. IFF сравнивает полученную от EEPROM последовательность с вычисленной ранее, если они сходятся - выдает сигнал глобального разрешения работы проекта.
Примеры кода на VHDL для такого способа организации защиты также приводятся. http://www.xilinx.com/bvdocs/appnotes/xapp780.zip

Итак в качетсве дополнительного ресурса для защиты используется одна микросхема с возможностью шифровки данных (в очень миниатюрном корпусе - 2 вывода) и некоторый ресурс FPGA (100 Slices+1кб блочной памяти+1пин). Остается только оценить степень защищенности такого способа. Сможет ли гипотетический РЭинженер перехватив зашифрованную послед. расшифровать ключ?? Или подключив логический анализатор и перехватив конфигурационную прошивку извлечь ключ оттуда??

А, где, вы, в FPGA собрались брать "некторую случ. послед"???

[3.14]

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

[des00]

Все зависит от длинны ключа и длинны последовательности

[Maksim]

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

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

вся защита тут держится на даласовской таблетке, а не на ПЛИСине.

[3.14]

2 Maksim
Как это нет случайности ...
После включения питания FPGA рожает, насколько я успел понять, псевдослучайную последовательность адресов, на основе ключа который "забит" в корке. На основе этого же ключа рождена прошивка EEPROM. После чтения данные сверяются и ...
Хотя может я чего сам не понял, потому как получается, записываем поток между FPGA<->EEPROM, отыскиваем данные которые вываливаются из EEPROM, потом контроллером имитируем саму EEPROM подставляя записанные двнные.
С другой стороны, "закрывашка" основана на PicoBlaze так что можно еще "сюрпризы" добавить.

А защиту, кроме как у виртекса, в самой FPGA не реализуешь.

[Guest_Pruga_*]

А, где, вы, в FPGA собрались брать "некторую случ. послед"???

Случайную последовательность генерирует FPGA, для этого в устройстве, добавляемого к проекту есть ГСЧ. В файле с VHDL кодами сказано "This module generates a serial stream of random (not pseudorandom) bits" т.е что он генерирует не псевдослучайную а "true random" - "истинно" случайную (такое бывает?). Я пока не разобрался как работает этот генератор, прилагаю его код ниже.

Хотя может я чего сам не понял, потому как получается, записываем поток между FPGA<->EEPROM, отыскиваем данные которые вываливаются из EEPROM, потом контроллером имитируем саму EEPROM подставляя записанные двнные.

При включении питания ПЛИС выдает каждый раз разную последовательность (генерируется ГСЧ). Следоваетельно и EEPROM возвращает каждый раз разный хэш. Поэтому идея с контролером сработает только если ГСЧ повторится, что по идеи должно быть исключено (или вероятность близка к 0).

Сообщение отредактировал Pruga - Jun 3 2006, 17:23

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

 RND.rar ( 2.27 килобайт ) Кол-во скачиваний: 373

 

[Maksim]

to 3.14

Ключ есть, полином есть, а сколько тактов это крутится?? Я так думаю каждый раз одинаковое количество раз.

to Pruga

код я посмотрел - там полином и... указание и маршрут разводки 2-х цепей
и, что там есть неопределённость?
и ещё ... cRING1<=transport TO01(RING1) after tNET1+tILOX-100 ps;
это как понимать?

[des00]

to 3.14

Ключ есть, полином есть, а сколько тактов это крутится?? Я так думаю каждый раз одинаковое количество раз.

to Pruga

код я посмотрел - там полином и... указание и маршрут разводки 2-х цепей
и, что там есть неопределённость?
и ещё ... cRING1<=transport TO01(RING1) after tNET1+tILOX-100 ps;
это как понимать?

ХММ по идее это для моделирования, похоже они, ручной разводкой, играют на нарушении tsu, th тригеров и получают рандом

[makc]

ХММ по идее это для моделирования, похоже они, ручной разводкой, играют на нарушении tsu, th тригеров и получают рандом

Да, где-то уже мелькала идея реализации ФДСЧ в ПЛИС с помощью игры на задержках элементов. Там, если мне не изменяет память, предлагалось сделать генератор на ЛЯ ПЛИС и использовать его колебания периода (он будет нестабилен), для получения битов случайной последовательности. Но на сколько это будет качественная случайная последовательность сказать сложно.

[Maksim]

остаётся только загнать этот код в ПЛИСину - и вытащить наружу эти биты, а потом обсчитать - и будет ясно насколько случайна эта последовательность

[makc]

остаётся только загнать этот код в ПЛИСину - и вытащить наружу эти биты, а потом обсчитать - и будет ясно насколько случайна эта последовательность

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

[Maksim]

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

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

[DmitryR]

Послушайте, а почему не использовать встроенный в, например Virtex/Stratix/ProASIC алгоритм? Ставится батарейка (а в ProASIC и без батарейки), с помощью нее в ПЛИС поддерживаются ключи декодирования, зашитые туда разработчиком. Прошивка кодируется парным ключом и зашивается в обычное конфигурационное PROM. Перехватывайте на здоровье, ключ - 128 бит. Батарейки хватает на десятилетия. Или я пропустил место в обсуждениях, где это было отметено?

[Maksim]

Послушайте, а почему не использовать встроенный в, например Virtex/Stratix/ProASIC алгоритм? Ставится батарейка (а в ProASIC и без батарейки), с помощью нее в ПЛИС поддерживаются ключи декодирования, зашитые туда разработчиком. Прошивка кодируется парным ключом и зашивается в обычное конфигурационное PROM. Перехватывайте на здоровье, ключ - 128 бит. Батарейки хватает на десятилетия. Или я пропустил место в обсуждениях, где это было отметено?

Всё дело в цене микросхем (для Xilinx) - Actel это несколько другая архитектура.
Посмотрите цены на Spartan-3E и Virtex - и всё станет ясно

[v_mirgorodsky]

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

Гораздо более серьезным вопросом является возможность считывания кода из EEPROM под электронным микроскопом. Если верить моим знакомым, то здесь за ATmega с битом защиты у них просили около 10-12k$ - не думаю, что далласовская EEPROM-ка будет стоить намного дороже.

[Guest_Pruga_*]

Сегодня разбирался с ГСЧ (RND.vhd). Загрузил весь проект в ISE, создал тестбенч для RND.vhd, на вход клока подал 50 МГц, а с выхода снимал случайную последовательность. При функциональном моделировании получается некоторая последовательность, (на случайность не проверял).

to 3.14

Ключ есть, полином есть, а сколько тактов это крутится?? Я так думаю каждый раз одинаковое количество раз.

to Pruga

код я посмотрел - там полином и... указание и маршрут разводки 2-х цепей
и, что там есть неопределённость?
и ещё ... cRING1<=transport TO01(RING1) after tNET1+tILOX-100 ps;
это как понимать?

Похоже эти задержки моделируют реальные, для выполнения функционального моделирования. В комментарии написано: "--timing simulation values for 2VP-6"

Вообщем работу этого генератора я себе представляю следующим образом: генерация случайных чисел базируется на создании М-последовательности (20-ти разрядный регистр (соответствующий примитивному полиному x^20+x^3+1), с обратными связями от 20 и 3 разряда, заведенными на вход через XOR4 элемент (выполненным на LUT)). Однако регистры с линейными обратными связями генерируют псевдослучайные последовательности, с периодом 2^n-1 (n-число разрядов), и то если соответсвующий многочлен примитивен, поэтому как я понял к обратной связи (2 оставшимся входам элемента XOR), подсоединяются 2 сигнала Ring1 и Ring2, которые представляют собой замкнутые петли (сигнал с выхода инвертора подается на его вход), о чем мне и сообщил синтезатор. Цепи Ring1 и Ring2 оттрасированы специальным образом (наверно для того, чтобы задержка была примерно известна). Таким образом к М-последовательности подмешиваются 2 сигнала, состояние которых в каждый момент времени неизвестно, чем видимо и обеспечивается "истинно" случайная последовательность.

Послушайте, а почему не использовать встроенный в, например Virtex/Stratix/ProASIC алгоритм? Ставится батарейка (а в ProASIC и без батарейки), с помощью нее в ПЛИС поддерживаются ключи декодирования, зашитые туда разработчиком. Прошивка кодируется парным ключом и зашивается в обычное конфигурационное PROM. Перехватывайте на здоровье, ключ - 128 бит. Батарейки хватает на десятилетия. Или я пропустил место в обсуждениях, где это было отметено?

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

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

Гораздо более серьезным вопросом является возможность считывания кода из EEPROM под электронным микроскопом. Если верить моим знакомым, то здесь за ATmega с битом защиты у них просили около 10-12k$ - не думаю, что далласовская EEPROM-ка будет стоить намного дороже.

Это значит, что если стоимость защищаемой информации меньше, чем эта сумма то защита хорошая

[Maksim]

проект с полином работает - проверил на 3-х платах со Спартаном-3 (200т.вентилей)
на выходе при каждом включении-выключении -появляются разные значения
"качество" шума не обсчитывал, еепромку не подключал...
...так, что ... работает мона пользовать

[3.14]

Ребята, дык в любом случае, по проволочке будет бпродить как адрес так и сами "секретные" данные. Тут никакого микроскопа не надо, чтобы за "миллион" включений платы всю ПЗУ скопировать.

[Maksim]

Ребята, дык в любом случае, по проволочке будет бпродить как адрес так и сами "секретные" данные. Тут никакого микроскопа не надо, чтобы за "миллион" включений платы всю ПЗУ скопировать.

по каким проводам?
Вместо далласовской еепромки, можно свой микроконтроллер ставить со своим алгоритмом аутентифткации