я занимаюсь RTL и о back-end-е имею смутное представление, поэтому глупые вопросы

вопрос про OTP (для TSMC разработка флаш обычно сильно тормозит и ее пока нет)
топологии этих макроячеек у меня нет, есть некое описание (достаточно халявное) - нужно выбрать или отказаться от этого вообще

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

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

технология m8 - я так понимаю, что для трассировки отводятся верхние слои, а "внутренности" ячейки трассируются на нижних слоях (например, артизан компилер генерит SRAM в 4-х нижних слоях), это так?

но предлагаемая ячейка OTP имеет все входы-выходы подключенные через IO PAD-ы, это значит что подкючать контроллер памяти надо через IO пады и вообще достаточно будет хорошей лупы чтобы считать?
ну и опять же - на фотографии чипа (на сайте, см ниже) - мактоячейки памяти хорошо видны - значит все 8 слоев занимает?

еще интересно, что это за
passive reverse-engineering techniques such as voltage contrast or hot spot detection
???

вот эти деятели (одна из альтернатив) утверждают, что обеспечивают Highly secured from unauthorized hacker за счет того, что их патентед транзистор с плавающим затвором неотличим от обычного КМОП
http://www.kilopass.com/e15/?CurrentItem=2&SubItem=1
но какой это имеет смысл?

вот еще вариант
http://www.ememory.com.tw/2-neobit.htm

проблема в том, что после всяких NDA присылают даташит, который шит, а не дата

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

может что-либо порекомендуете почитать полезное для понимания проблемы?

еще добавлю - можно сделать какой-либо аппаратный DES-подобный кодер, который заливает флаш(ОТР)
но где ключ хранить?

под реверс инжинирингом в случае такого цела я понимаю подключение иголками к падам ячейки (ну а если их нет, то гораздо сложнее, тем более если не на верхнем уровне) и считывание, а то чего-то не объяснил, sorry

Слава AlexanderY! От такую идею подсказал...
http://www.caxapa.ru/echo/arm.html?id=51028

ну вообще-то AlexanderY описал стандартный подход защиты ПЛИС - типа ставим что-то секретное, что позволяет запрос-ответ.

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

сменой ключа обеспечивается защита.

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

с фиксированным ключем - нафига мне ОТР - закриптовал прошивку во внешней FLASH и гружу ее внутренним секретным алгоритмом (можно даже не аппаратный - а код на синтезированном ROM) - хрен кто вскроет, кто этого ROM не знает

Где-где, в ROM. Для пущей надежности от ковыряния в фулл-кустом блоке, чтобы это не был стандартный мемори-компилер, известный корчевальщикам. Только не DES наверное, а что-то несимметричное, чтобы получение ключа шифрования врагом не дало возможности разобрать прошивку. Тогда можно даже апгрейды врагу доверить.

ROM - как я понял, должен быть перезаписываемый

опять же с NV памятями большая бяда для 0.13 - там не то что компилеров, готовых IP трудно достать

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

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

Вам, скорее всего, задача понятна - один АЗИК на семейство приборов, то есть в low-cost приборах функциональность ограничена программой (там даже хуже - переход из low-cost в high-cost - возможен в процессе эксплуатации, путем смены куска программы)

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

но вопрос в защите основновного кода/отладочного интерфейса, чтобы не могли отдебагить.
структурно все достаточно красиво, но вопрос насколько устойчива реализация ОТР макросела, и как ее можно повысить.
нужно предполагать, что стоимость взлома может быть порядка 100К

да, весь код во внутреннем OTP не умещается, да и он должен быть модифицируемым - в ОТР только секретный загрузчик + ключ/ID

Сообщение отредактировал yes - Mar 31 2006, 09:50

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

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

а технологический вопрос - есть ли методы предотвратить стирание ОТР ренгеном?

собственно в защите, необходимо два "удачных" действия взломщика - считывание (возможно разрушающее), и серийное перепрограммирование (стирание) ОТР в приборе

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

Дублировать ячейку, и в дубле всегда должна быть инверсия, т.е. допустимы 10, или 01, 00 или 11 - выключаемся. Тогда если что то трут топором (ренгеном, ультрафиолетом итп) то обе ячейки сваливются в одно значение. А если они близко стоят то стереть взвести только одну очень сложно.

подписать OTP хотябы тем же crc - или вообще на весь накопитель, включая OTP добавлять CRC

ну а как быть с начальной прошивкой - ведь с завода чип приходит такой же, как и после ренгена...

Если не секрет, что у Вас за фирма, и что делаете ?

http://javad.com/