Свет в этой профессии/должности временами действительно есть, и очень даже яркий бывает — это когда новый архитектор сжигает всё что сделал предыдущий :)
Ну вот именно, PUF — это вариант натурального/природного ID, который получается получается случайным для каждого экземпляра (если целенаправленно не менять начинку чипа).
Но только никакой защиты от нелегального копирования/клонирования это не даёт. Собственно это и раздражает в заголовке.
Для защиты нужна привязка к PUF-ID — а вот тут начинается совсем другая история…
Добавлю про «нестабильность ПЗУ» — можно эмулировать с любой разумной точностью, записав в настоящее ПЗУ/EEPROM нужные коэффициенты (гейтов/транзисторов/площади конечно больше съест, но не суть).
В утверждении "PUF защищает от копирования" ощущается некоторая наивность. Так или иначе, некий PUF-блок можно заменить на ПЗУ, и даже добавить туда нестабильность, если она потребуется. Просто больше возни, а отличия будут видны только при взгляде на кристалл в микроскоп.
С точки зрения софта/прошивок всё сведется к набору ID-шников, которые где-то будут записаны в табличном виде. Соответственно, проверка сведется к проверке наличия конкретного ID в этом списке.
Если говорить про комплекс мер (например DS28E01 с расшифровкой прошивки внутри FPGA или DSP/SoC), то для этого PUF совсем не обязателен.
Байка почти по теме:
Давным-давно, когда в ходу были дискеты и всяческие методы "защиты от копирования", я работал "программистом" в одной честной фирме. Честной — в том смысле, что они купили на все 5 бухгалтерских компов лицензии на софт с "ключевыми дискетами".
Первый месяц купленный софт более-менее работал, а потом начались проблемы с этими "ключевыми дискетами". Их поменяли один раз, потом еще раз, на третий я разозлился и сделал TSR, который перехватывал INT13, сравнивал сигнатуру у caller-а и при совпадении в нужном месте ставил jmp. Все.
А "ключевые дискеты" те были в чистом виде PUF, там куча секторов то не всегда читалась, причем с разной вероятностью на разных дисководах. Предполагаю что целый оркестр битов был записан с разным уровнем намагничивания. Поэтому некая вторая версия защиты предполагала процесс активации, т.е. выдавался некий код (зависящий от дисковода), который нужно было сообщить производителю и получить в ответ ключ...
Короче, уйма усилий была потрачено на защиту, которая лечилась примерно одним "гвоздем".
libmdbx — это допеределанный форк LMDB, который продолжает развиваться. В README перечислены примерно все 29 сделанных доработок. О запланированных features можно подсмотреть в конце этих слайдов от доклада c недавнего "Hypeload++2017". Плюс в ближайшее время будет статья на "Хабре".
Нашел для себя хороший кейс-задачку для собеседований.
Если закрыть глаза на то, что теперь это знают «почти все» или поменять условия, то ответ на «объясните почему так» выглядит хорошей проверкой как на знание принципов, так и на умение соображать.
Хм, очень странно и неожиданно что PVS еще не ловит такое.
В целом ощущение что Manticore один раз (когда-то давно) прогнали через Coverity, но пофиксили только часть, а Аксенову все еще лень(?) прикрутить такой CI через travis.org
Этим занимаются части операционной системы, отвечающие за функцию CryptGenRandom в Windows и псевдоустройство /dev/random в Linux.
Ну всё правильно, только это не имеет непосредственного отношения к инфинеоновскому контроллеру, его прошивке и сопутствующих библиотекам. Более того, я соглашусь что моё многословие по теме в том комментарии было лишним. Особенно в ключе того, что дело там в «сите» (генераторе) простых чисел, а не где-то ещё.
Тем не менее, с генераторами «случайности» не всё очевидно и упомянутая позиция Линуса совершенно оправдана (т.е. мышиные телодвижения таки попадают в /dev/random даже при наличии RDRAND у CPU). Как говорится «Добрым словом и револьвером можно добиться большего, чем одним добрым словом» (Аль Капоне).
Чушь, вы отстали примерно на пару десятилетий. Уже давно в процессорах аппаратные генераторы случайных чисел на тепловых шумах.
На всякий — в эксплуатации находятся достаточно процессоров без RDRAND или аналогов этой инструкции. При этом собранную "случайность" всё равно нужно правильно использовать...
При формировании ключей используется генератор случайных чисел, точнее должен использоваться. Но на практике, как правило, нет хорошего доступного источника настоящей случайности.
Технически проблема решается сбором «примерно случайной» информации: как вы нажимаете на клавиши или водите мышем, на деле все подходящие «внутрисистемные события» (точное время поступления аппаратных прерываний и т.д.). При этом крайне важно собрать/накопить достаточное количество «случайности» и затем правильно нафаршировать ею ключ. Типичная ошибка (утрированно) — начало ключа случайное, а потом не очень (пошли по кругу или ещё хуже).
Так вот, суть проблемы в том, что внутри библиотечки необходимая «случайность» либо плохо собиралась, либо плохо использовалась, либо и то и другое — собственно не важно. Главное, что в результате генерируемые ключи шифрования не всегда полностью случайны и проявляют существенные статистические искажения, в том числе корреляцию между отдельными битами и т.д.
Соответственно, зная причину и природу этих отклонений можно найти секретный ключ несравнимо быстрее, чем полным перебором.
Не стану минусовать статью, так как автор перевода точно не виноват.
Но, думаю, стоит пояснить, что тут не так.
Самое главное в оптимизации — это, конечно, результат. Примерно по секундомеру или по количеству необходимой памяти. Беда в том, что "просто оптимизация", особенно описываемые механические приёмы/трюки, быстро приводят к попыткам оптимизировать "всё что плохо лежит".
Выходит даже не преждевременная оптимизация, а это code style — часто очень трудно читаемый.
В таком code style можно написать пару тысяч строк кода, потом будет просто трудно и неудобно. Иногда это оправдано и даже дано. Например, разработчики привыкшие делать именно так, могут автоматически сделать супер-быстрым почти любой код (по любому ТЗ). Но не дай бог, чтобы такого кода было много — его реально сложно поддерживать, дорабатывать, верифицировать, высока вероятность внесения дефектов и т.д. Тем не менее, это не основное "зло" в статье, это побочный эффект.
Главное в оптимизации — правильный вкус: чувство меры и ощущения стиля одновременно. Это трудно достижимый навык, некий дзен, мастерство в искусстве. Уже было много раз составлялись всяческие своды правил и/или наборы механических приёмов — результаты плачевны (хотя точно больше нуля). Более того, получить чувство меры невозможно без набивания достойных шишек.
Собственно, основной принцип оптимизации давно озвучил Буонарроти = уберите лишнее. Просто избавьте машину от лишней работы.
А вот тут внезапно выясняется, что для понимания "лишнего" нужно хорошо представлять как работает машина: всяческие кэш-линии, MESI, зависимости по данным в конвейере u-ops, что делает оптимизирующий компилятор, зачем те или иные конструкции языка, когда/зачем/как случается векторизация, и ещё очень-очень много. И убирать нечно "лишнее" нужно там, где оно действительно лишнее, но не поворачивать реки.
Так вот, основной минус этой статьи в том, что вместо понимания "как на самом деле" по-большей части предлагается культ Карго (делайте так и будет вам счастье).
Но только никакой защиты от нелегального копирования/клонирования это не даёт. Собственно это и раздражает в заголовке.
Для защиты нужна привязка к PUF-ID — а вот тут начинается совсем другая история…
Добавлю про «нестабильность ПЗУ» — можно эмулировать с любой разумной точностью, записав в настоящее ПЗУ/EEPROM нужные коэффициенты (гейтов/транзисторов/площади конечно больше съест, но не суть).
В утверждении "PUF защищает от копирования" ощущается некоторая наивность. Так или иначе, некий PUF-блок можно заменить на ПЗУ, и даже добавить туда нестабильность, если она потребуется. Просто больше возни, а отличия будут видны только при взгляде на кристалл в микроскоп.
С точки зрения софта/прошивок всё сведется к набору ID-шников, которые где-то будут записаны в табличном виде. Соответственно, проверка сведется к проверке наличия конкретного ID в этом списке.
Если говорить про комплекс мер (например DS28E01 с расшифровкой прошивки внутри FPGA или DSP/SoC), то для этого PUF совсем не обязателен.
Байка почти по теме:
Давным-давно, когда в ходу были дискеты и всяческие методы "защиты от копирования", я работал "программистом" в одной честной фирме. Честной — в том смысле, что они купили на все 5 бухгалтерских компов лицензии на софт с "ключевыми дискетами".
Первый месяц купленный софт более-менее работал, а потом начались проблемы с этими "ключевыми дискетами". Их поменяли один раз, потом еще раз, на третий я разозлился и сделал TSR, который перехватывал INT13, сравнивал сигнатуру у caller-а и при совпадении в нужном месте ставил jmp. Все.
А "ключевые дискеты" те были в чистом виде PUF, там куча секторов то не всегда читалась, причем с разной вероятностью на разных дисководах. Предполагаю что целый оркестр битов был записан с разным уровнем намагничивания. Поэтому некая вторая версия защиты предполагала процесс активации, т.е. выдавался некий код (зависящий от дисковода), который нужно было сообщить производителю и получить в ответ ключ...
Короче, уйма усилий была потрачено на защиту, которая лечилась примерно одним "гвоздем".
Если вам приглянулась LMDB, то советую глянуть libmdbx и libfpta.
libmdbx — это допеределанный форк LMDB, который продолжает развиваться. В README перечислены примерно все 29 сделанных доработок. О запланированных features можно подсмотреть в конце этих слайдов от доклада c недавнего "Hypeload++2017". Плюс в ближайшее время будет статья на "Хабре".
Если закрыть глаза на то, что теперь это знают «почти все» или поменять условия, то ответ на «объясните почему так» выглядит хорошей проверкой как на знание принципов, так и на умение соображать.
В целом ощущение что Manticore один раз (когда-то давно) прогнали через Coverity, но пофиксили только часть, а Аксенову все еще лень(?) прикрутить такой CI через travis.org
Только за это стоит минуснуть.
Ну всё правильно, только это не имеет непосредственного отношения к инфинеоновскому контроллеру, его прошивке и сопутствующих библиотекам. Более того, я соглашусь что моё многословие по теме в том комментарии было лишним. Особенно в ключе того, что дело там в «сите» (генераторе) простых чисел, а не где-то ещё.
Тем не менее, с генераторами «случайности» не всё очевидно и упомянутая позиция Линуса совершенно оправдана (т.е. мышиные телодвижения таки попадают в /dev/random даже при наличии RDRAND у CPU). Как говорится «Добрым словом и револьвером можно добиться большего, чем одним добрым словом» (Аль Капоне).
На всякий — в эксплуатации находятся достаточно процессоров без RDRAND или аналогов этой инструкции. При этом собранную "случайность" всё равно нужно правильно использовать...
С другой стороны, по-сути собранная случайность плохо использовалась.
Насколько я сейчас понимаю проблема происходит от primesieve.org, точнее в последствиях en.wikipedia.org/wiki/Wheel_factorization
Технически проблема решается сбором «примерно случайной» информации: как вы нажимаете на клавиши или водите мышем, на деле все подходящие «внутрисистемные события» (точное время поступления аппаратных прерываний и т.д.). При этом крайне важно собрать/накопить достаточное количество «случайности» и затем правильно нафаршировать ею ключ. Типичная ошибка (утрированно) — начало ключа случайное, а потом не очень (пошли по кругу или ещё хуже).
Так вот, суть проблемы в том, что внутри библиотечки необходимая «случайность» либо плохо собиралась, либо плохо использовалась, либо и то и другое — собственно не важно. Главное, что в результате генерируемые ключи шифрования не всегда полностью случайны и проявляют существенные статистические искажения, в том числе корреляцию между отдельными битами и т.д.
Соответственно, зная причину и природу этих отклонений можно найти секретный ключ несравнимо быстрее, чем полным перебором.
Не стану минусовать статью, так как автор перевода точно не виноват.
Но, думаю, стоит пояснить, что тут не так.
Самое главное в оптимизации — это, конечно, результат. Примерно по секундомеру или по количеству необходимой памяти. Беда в том, что "просто оптимизация", особенно описываемые механические приёмы/трюки, быстро приводят к попыткам оптимизировать "всё что плохо лежит".
Выходит даже не преждевременная оптимизация, а это code style — часто очень трудно читаемый.
В таком code style можно написать пару тысяч строк кода, потом будет просто трудно и неудобно. Иногда это оправдано и даже дано. Например, разработчики привыкшие делать именно так, могут автоматически сделать супер-быстрым почти любой код (по любому ТЗ). Но не дай бог, чтобы такого кода было много — его реально сложно поддерживать, дорабатывать, верифицировать, высока вероятность внесения дефектов и т.д. Тем не менее, это не основное "зло" в статье, это побочный эффект.
Главное в оптимизации — правильный вкус: чувство меры и ощущения стиля одновременно. Это трудно достижимый навык, некий дзен, мастерство в искусстве. Уже было много раз составлялись всяческие своды правил и/или наборы механических приёмов — результаты плачевны (хотя точно больше нуля). Более того, получить чувство меры невозможно без набивания достойных шишек.
Собственно, основной принцип оптимизации давно озвучил Буонарроти = уберите лишнее. Просто избавьте машину от лишней работы.
А вот тут внезапно выясняется, что для понимания "лишнего" нужно хорошо представлять как работает машина: всяческие кэш-линии, MESI, зависимости по данным в конвейере u-ops, что делает оптимизирующий компилятор, зачем те или иные конструкции языка, когда/зачем/как случается векторизация, и ещё очень-очень много. И убирать нечно "лишнее" нужно там, где оно действительно лишнее, но не поворачивать реки.
Так вот, основной минус этой статьи в том, что вместо понимания "как на самом деле" по-большей части предлагается культ Карго (делайте так и будет вам счастье).