[acex2 0]

кстати с полиномом совет весьма вредный -

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

 

по-хорошему - надо ставить какие-то готовые элементы (которые криптографически проверены)

минималистический - что-то типа Keloq

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

<{POST_SNAPBACK}>

 

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

<{POST_SNAPBACK}>

 

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

 

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

[Harbour 0]

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

[acex2 0]

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

<{POST_SNAPBACK}>

 

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

[Maksim 0]

кстати с полиномом совет весьма вредный -

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

 

по-хорошему - надо ставить какие-то готовые элементы (которые криптографически проверены)

минималистический - что-то типа Keloq

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

<{POST_SNAPBACK}>

 

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

<{POST_SNAPBACK}>

 

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

 

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

<{POST_SNAPBACK}>

Берётся два полинома - предположим, длинный и короткий.

Начальное заполнение полиномов берём от датчика случайных чисел.

На вход длинного полниома заводим выход короткого.

Микроконтроллер при включении питания сообщает в FPGA номер

первого включения N=1(). FPGA полученный номер складывает с какой-то

секретной константой и результат на вход короткого полнинома и прокрутить его

M-тактов (M должно быть больше основания полинома (М=20, крутим 25-30 тактов и т.д.)).

Потом крутим короткий полином и результат подаём на вход длинного полинома,

и тоже прокручиваем энное количество тактов.Микроконтроллер тоже самое проделывает у

себя внутри, после чего результат сообщает в FPGA (в явном виде, с переставленными

битами и т.д.). После каждого включения питания при такой системе выдаваемые ответы

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

сбиваться случайным образом за счёт короткого полинома.

Но это так что первое пришло в голову, а лучше я согласен - если есть место

то зашить туда шифратор с ключом и сообщать FPGA секретную константу для запуска, котороая

будет шифроваться гамированием, например (синхропосылка+зашифрованная константа).

[eugene 0]

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

[Maksim 0]

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

<{POST_SNAPBACK}>

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

[acex2 0]

Берётся два полинома - предположим, длинный и короткий.

Начальное заполнение полиномов берём от датчика случайных чисел.

На вход длинного полниома заводим выход короткого.

Микроконтроллер при включении питания сообщает в 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 0]

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

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

 

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

<{POST_SNAPBACK}>

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

[acex2 0]

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

 

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

[Harbour 0]

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

<{POST_SNAPBACK}>

 

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

<{POST_SNAPBACK}>

Народ отклонился от темы, мое 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 0]

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

 

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

 

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

[Maksim 0]

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

 

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

<{POST_SNAPBACK}>

 

Теперь понятно.

Как говорится теже яйца только в профиль :laugh: :a14:

[driver73 0]

я думаю так

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

 

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

[makc 231]

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

<{POST_SNAPBACK}>

 

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

[acex2 0]

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

<{POST_SNAPBACK}>

 

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

<{POST_SNAPBACK}>

 

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