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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

Насущная потребность заставила меня поднять из под спуда эту тему. А тема актуальна и по сей день. Постановка задачи остается той же: необходимо обеспечить защиту прошивки ПЛИС, желательно более простыми методами. Немного поискав на сайте 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 собрались брать "некторую случ. послед"???

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

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

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

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

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

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

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

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

to 3.14

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

to Pruga

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

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

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

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

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

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

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

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

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

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

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

Похоже эти задержки моделируют реальные, для выполнения функционального моделирования. В комментарии написано: "--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 сигнала, состояние которых в каждый момент времени неизвестно, чем видимо и обеспечивается "истинно" случайная последовательность.


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


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

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

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

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