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

Где прочитал? Что за ПЛИС?

Что-то вроде вот этого, наверное: Altera Unique Chip ID IP Core.
Смотря как реализовано будет, а то ведь есть варианты, как взломать.

В свое ядро интегрировать ее, конечно, можно - как и любой lpm-модуль.

А вот что касается "нормальности" подхода, то тут много вопросов.
А что делать заказчику, если у него микросхема, для которой Вы сделали постсинтетический нетлист, вышла из строя? Отправлять Вам новый Unique ID другой микросхемы?
А как Вы будете это контролировать (т.е. действительно ли у заказчика микросхема вышла из строя, или он просто мухлюет и хочет получить второй экземпляр бесплатно)?
А если у заказчика серия в 100500 экземпляров устройства? Вы готовы перекомпилировать своя IP-ядро для каждого экземпляра устройства заказчика?
И прочая, прочая...

Производители IP-ядер (в т.ч. Altera) делают по-другому. Если излагать упрощенно, приближая к Вашему случаю - они предоставляют заказчику два файла:
1)зашифрованные исходник (ну или зашифрованный edif/vqm нетлист);
2)лицензионный файл, который позволяет этот зашифрованный файл использовать.
Причем зашифровать файл и сделать лицензионный файл можно так, чтобы компиляция была возможна только для выбранных семейств ПЛИС (одного или нескольких), и только на одном компьютере.
Но при этом у заказчика технически нет ограничений на тираж изделий, в которых используются микросхемы, для которых разрешена компиляция.

За подробностями - в личку.

Не проблема, такое можно автоматизировать скриптами через командную строку, в квартусе это просто делается, и собирать множество параллельно. Можно сократить число прошивок, если одна будет прошивка рассчитана сразу на 10-100 различных ID

Можно и зайца научить курить (с) Но зачем?
Еще раз отмечу - вопрос это более административный, чем технический.

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



Если это SRAM-based ПЛИС и конфигурация хранится во внешней флешке (90% случаев), то hmac(fpga_id) можно хранить на ней. В этом случае битстрим будет всегда один и тот же.
Разработчик IP-корки запросто может нагенерировать ваши 100500 хэшей по 100500 id-шника. Заказчику остаётся только запрограммировать на флеш битстрим + рядом положить соответствующий fpga-ке hmac(fpga_id). Hmac привёл для примера. В любом случае хэш можно усложнить/упростить на усмотрение разработчика.

Сообщение отредактировал Inanity - Oct 27 2017, 13:20

Коллеги, постарайтесь взглянуть на проблему шире.
Как заказчик будет получать список своих Unique ID в условиях серийного производства?
Нужно будет на каждом экземпляре смонтированного устройства запустить специальный проект (допустим, его предоставит разработчик IP-ядра), который будет возвращать ID использованной в этом экземпляре микросхемы.
Это требует времени. Затем, пока разработчик ядра генерирует прошивки или хэши, все эти платы надо как-то хранить. И еще проблема - придется либо как-то маркировать каждый экземпляр, либо для каждого экземпляра повторять процедуру чтения ID после получения от разработчика кучи прошивок/хэшей - чтобы восстановить, какому именно файлу прошивки (или хэшу) какой экземпляр устройства соответствует. Все это усложняет производственый процесс и увеличивает накладные расходы.

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

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

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

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

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

Извините, что целый день отсутствовал, работа... Интересный разговор начался...
Сразу конечно стоило оговорить: продукт мелкосерийный, с высокой добавленной стоимостью... Так что передача UID и синтез с ним - не проблема. Вопрос, который я подразумевал, но открыто не задал - что делать, если таких ядер несколько и каждое будет использовать Altera Unique Chip ID IP Core, что делать?
Доступа ко всему проекту нет... Неужели все так и передают - сколько хочешь, столько и копируй?
Неужели никто подобными вещами не озадачивался?

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



Можно без UID. Есть способ защиты от копирования на основе внешней сrypto-memory. Если кратко, то в ip-ядре хранится ключ K и генератор случайных чисел (ГСЧ), во внешней сrypto-memory тоже хранится этот ключ К (который нельзя считать, только перезаписать). После включения питания ГСЧ выдаёт случайное число, которое отправляет во внешнюю сrypto-memory, она делает с этим числом некоторое преобразование, используя ключ К и отправляет результат обратно в ПЛИС, в ip-core. IP-core тоже выполняет аналогичное преобразование, но уже на своей стороне с тем же ключом и числом. Если результаты от сrypto-memory и ip-core совпадают, то аутентификация успешна. Подробнее есть документ xilinx: https://www.xilinx.com/support/documentatio...tes/xapp780.pdf
От себя скажу, что в документе описывается сrypto-memory с SHA-1. Этот хэш на сегодняшний день не считается безопасным, необходимо применять сrypto-memory на основе SHA-2 или SHA-3. Данный подход тоже отнюдь не изящно масштабируется, т.к. под каждую ip-core нужна будет своя сrypto-memory (хотя их спокойно можно посадить на одну шину i2c или 1-wire в зависимости от сrypto-memory). Ещё есть риск накосячить с реализацией ГСЧ на ПЛИС.

Сообщение отредактировал Inanity - Oct 27 2017, 17:05

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

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

Тут нужен не доступ ко всему проекту, а возможность потребовать от заказчика несколько (1 - 2) внешних портов на ПЛИС + возможность поставить снаружи свой чип. Если проект работает на готовой плате - это маловероятно. Если плата проектируется - реально. К этим пинам подключается специализированная память - EEPROM с криптоядром. При условии корректной реализации от пользователя потребуется однажды выполнить активацию устройства и все. Перехват обмена с внешним чипом никак не поможет отключить защиту (опять-таки - _при_условии_корректной_реализации_).
Далее порты ядра с указанными констрейнами пробрасываются наружу и все остальное уже никак не зависит от внешнего проекта. Таких защитных чипов в системе может быть несколько.

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

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

Административно - понятно. Технически значит никак. Спасибо всем...