А я не согласен с Вами. Чисто математически наличие внутренней защищенной памяти повышает стойкость системы к взлому при одном и том же шифровании потока. Возражения принимаются исключительно математическим доказательством неверности моего высказывания.

Докучи ключик всего-то 128 бит, и выковырять их с чипа мне представляется значительно более простой операцией, чем выковырять оттуда еще и весь массив данных.

Чисто математически соглашусь с Вами, но чисто практически, повышение стойкости за счет расположения на кристалле, считаю весьма незначительным по сравнению с AES.

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

Зато будет ОЧЕНЬ важно, снимать два массива с разных блоков памяти, или один. Так как разбираться в том, где же та точка, с которой можно что-то снять, придется именно вручную.

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

как правило сейчас чтото стартует внутри из флеш и потом начинает раскручиваться

вот в этом моя и беда


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

мне бы все с точностью на оборот чтобы все было тупо

Нука-нука, и какая же это ФПГА защищена от залива? У известных мне флешовых (это LatticeXP, LatticeXP2, MAX-II) защиты от залива нет, и есть внешние ноги, которыми можно отключить автостарт из встроенной флеш. А через JTAG вообще можно сделать всегда и все.

вы читаете что я пишу ? - идет ТЕНДЕНЦИЯ - на мк тоже все начиналось с этого
сначала защищали только слив - а теперь и запись защищают
а начиналось точно также- вот я этого и опасаюсь - кому защита благо - а кому и вред
чтото можно было отключить - а теперь в некоторых ничего нельзя сделать
и не только в МК - но и в обычных микросхемах - тех же видеосенсорах
очень часто нет ножки RESET !!!


просто таких как я очень мало - и мне эта защита только вред
а вам может защита и нужна для чегото - и вам она в радость

Повторю Вашу фразу:



И свой вопрос - и в какой же именно флешовой ФПГА это "начинается"?

ошибаетесь - после установки ключа в ХР2 можно залить только закриптованую этим ключем, некриптованую в этот кристалл не залить
это один из плюсов, имхо

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

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

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

А это точно? По моей информации ключ тоже стираем, он вроде не OTP. Или я не прав?


Что касается меня - то конфиг. ПЗУ просто не влезет физически (для масштаба - резюки там в большинстве своем 0402, нижняя сторона платы забита под завязку мелочью), а тайм-ту маркет вовсе не на первом плане... Что же касается шифрования - это только лишняя возможность того, что ключ можно либо потерять, либо украсть, при условии, что (в моем случае) прибор и так нельзя проапгрейдить без доп-оборудования, у него схема HS-USB-трансивер->ПЛИС->сериальный линк->ПЛИС->выход, и по любому для апгрейда необходимо прислать прибор в техподдержку.

TN1109 и TN1142, так же есть документ в латтиском дистрибутеве, где прописана процедура загрузки по SPI энкрипнутого модуля во флаш/sram - там расписано в деталях (если нужно точное название, то мне нужно поискать)

The LatticeXP2 will only configure from a file that has
been encrypted with the same 128-bit encryption key that is programmed into the LatticeXP2

у меня сложилось мнение, что механизм декодирования у XP2 абсолютно такой же как и в ECP2S, по крайней мере в доках на XP2 ссылаются TN1109

Like the LatticeECP2/M, the
LatticeXP2 family also offers the 128-bit Advanced Encryption Standard (AES) to protect the externally stored pro-
gramming file.
....
The next step is to program the 128-bit encryption key into the one-time programmable fuses on the
LatticeECP2/M.

по крайней мере, процедура стирания/замены ключа для XP2 нигде не встречалась

пока что я не получил от латтиса энкрипшен модуль (жду), надеюсь скоро проверю

Очень интересно. Что в ECP2/M OTP это я знаю, а вот что и в XP2 тоже OTP, а не кусок флеши, не знал.

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

то есть функционально ОТР, а реализовано на флэши

по крайней мере я так понял


--------------

btw: а стирание этого ключа (тем же лучом, если это возможно) ничего не даст, так как во флашке хранится криптованая прошивка
в то время как стирание read-only бита в неэнкриптнутом варианте ХР2 позволяет теоретически слить прошивку

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

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

я не интересовался деталями JTAG доступа (только SSPI), так как предполагал, что JTAG в туле (ispvm) есть, а в железке доступ только по SSPI будет

сейчас посмотрел LatticeXP2_Advanced_Security.pdf - там все процедуры работы по JTAG написаны
вроде как можно стереть ключи и вернуть в исходное состояние

вот это самое основное - в этом вся бЯда - для лично меня

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




знать ключ это все равно что нет защиты





обычно они любят еще и jtag отрубать - навсякий случай
и процедуры становятся недоступными

у некоторых есть спец манипуляции по разлочке залоченного
но у некоторых либо не описана процедура снятия по jtag
либо вообще не зная ключа ничего нельзя сделать