хмм вопрос стоял " Защита данных 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).

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

to 3.14

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

to Pruga

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

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

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