Comments 39
Отличная статья, спасибо. Интересный случай с кубиком :)
На счет кубика — много раз слышал об использование такого трюка :).
Хорошей идеей будет собирать внешние события ДО того, как будет нужно сгенерить число, и сохранять их в EEPROM, чтобы сброс питания не приводил к одинаковым результатам.
Генерация от внешнего источника энтропии подвержена атаке с помощью перерезания дорожки, ведущей туда. После этого достаточно подключить туда источник опорного напряжения, и бинго (например, если питание идет от 5 вольт, воткнуть туда 5.5 и будут только единицы, и шум не поможет).
Так что, ИМХО, только внутренние источники, зависящие от внешних параметров, и не сбрасывающиеся при пропадании питания. Причем сколько там получится обычных таймеров за один watchdog — получим несколько чисел (последовательных). Надо разницу фаз брать, причем примешивать к предыдущим значениям, а таймер переиничивать в main, с задержками, зависящими от предыдущего сгенеренного числа, к примеру…
Генерация от внешнего источника энтропии подвержена атаке с помощью перерезания дорожки, ведущей туда. После этого достаточно подключить туда источник опорного напряжения, и бинго (например, если питание идет от 5 вольт, воткнуть туда 5.5 и будут только единицы, и шум не поможет).
Так что, ИМХО, только внутренние источники, зависящие от внешних параметров, и не сбрасывающиеся при пропадании питания. Причем сколько там получится обычных таймеров за один watchdog — получим несколько чисел (последовательных). Надо разницу фаз брать, причем примешивать к предыдущим значениям, а таймер переиничивать в main, с задержками, зависящими от предыдущего сгенеренного числа, к примеру…
Спасибо за дополнения, добавил в статью.
А по поводу сохранение переменной состояния в EEPROM — не вижу особых преимуществ. Атака в данном случае очень простая: выключаем питание, перешиваем EEPROM нужными нам данными, включаем обратно, PROFIT!11
Далеко не все контроллеры имеют возможность залочить EEPROM от изменения при помощи программатора.
Далеко не все контроллеры имеют возможность залочить EEPROM от изменения при помощи программатора.
Преимущества просты:
1. сквозная генерация чисел. Часто видел людей, которые завязывались на таймеры, потом включали прибор, и у них — 2,4,19,3… выключали, включали — 2,4,19,3… то есть одинаковое поведение после ресета. Просто потому что прибор лежит в кондиционированном помещении, стабильность генераторов хорошая, последовательность всегда одинаковая. А тут она будет продолжаться.
2. Да, не все, но как правило, все же лочат. Многие лочат так, что стереть можно только вместе с прошивкой.
3. Можно писать в EEPROM программы, но это уже от применяемого контроллера зависит. Насколько я знаю, считать EEPROM сложно, проще стереть и записать нули. Но это просто добавляется проверка на чистоту EEPROM/CRC.
1. сквозная генерация чисел. Часто видел людей, которые завязывались на таймеры, потом включали прибор, и у них — 2,4,19,3… выключали, включали — 2,4,19,3… то есть одинаковое поведение после ресета. Просто потому что прибор лежит в кондиционированном помещении, стабильность генераторов хорошая, последовательность всегда одинаковая. А тут она будет продолжаться.
2. Да, не все, но как правило, все же лочат. Многие лочат так, что стереть можно только вместе с прошивкой.
3. Можно писать в EEPROM программы, но это уже от применяемого контроллера зависит. Насколько я знаю, считать EEPROM сложно, проще стереть и записать нули. Но это просто добавляется проверка на чистоту EEPROM/CRC.
*сохранениЯ
UFO just landed and posted this here
Плавающий бит использовали на ПЗУ стираемых ультрафиолетом. В микроконтроллерах такой финт не пройдет. Хотя, если во время записи отключить питание…
Рисунок такой ПЗУ размещен в начале статьи.
Если во время записи отключить питание...
В прошлых ревизиях контроллеров ATMega (кажется) был такой баг, что при пониженном (но еще в пределах номинального) напряжении питания запись в EEPROM вызывала случайные повреждения содержимого случайных ячеек. Пользу из этого бага никто так и не научился извлекать :)
С EEPROMомом есть другая фишка, ведь он мягко говоря не вечен!
Его можно задрючить так, что отдельные адреса будут дохлые, и их можно считать, и даже попытаться изменить их состояние, только оно уже не изменится :-)
А вообще, если хорошо разбираться в технологии производства микросхем, и иметь широкий кругозор, то есть огромное количество способов простебаться, даже над профессиональным реверс инженером.
Одна из излюбленных мною проверок на подлость, заключается в программном измерении паразитных монтажных емкостей и индуктивностей.
Подлецы на столько наивны, что думают, если разработчик не залочил прошивку на своей макете, то ему можно не платить, и ничто же сумняшеся льёт её в свои поделки, и сталкиваясь с массовым возвратом, долго и мучительно ищет проблему в схеме питания, пока не осознает что заплатить таки придётся ещё и за подлость :-)
PS. И раз уж речь пошла про системы шифрования, не стоит забывать о таком инструменте исследования как напильник, микроскоп и контакты к кристаллу, это всё лишь вопрос бюджета.
Его можно задрючить так, что отдельные адреса будут дохлые, и их можно считать, и даже попытаться изменить их состояние, только оно уже не изменится :-)
А вообще, если хорошо разбираться в технологии производства микросхем, и иметь широкий кругозор, то есть огромное количество способов простебаться, даже над профессиональным реверс инженером.
Одна из излюбленных мною проверок на подлость, заключается в программном измерении паразитных монтажных емкостей и индуктивностей.
Подлецы на столько наивны, что думают, если разработчик не залочил прошивку на своей макете, то ему можно не платить, и ничто же сумняшеся льёт её в свои поделки, и сталкиваясь с массовым возвратом, долго и мучительно ищет проблему в схеме питания, пока не осознает что заплатить таки придётся ещё и за подлость :-)
PS. И раз уж речь пошла про системы шифрования, не стоит забывать о таком инструменте исследования как напильник, микроскоп и контакты к кристаллу, это всё лишь вопрос бюджета.
Спасибо!
Кажется, это первая относительно «взрослая статья» по микроконтроллерам на хабре!
от себя добавлю:
1 еще в качестве источникоа энтропии можно использовать встроенный датчик температуры (он обычно и делается не калиброваным)
2 некоторые контроллеры включают в себя защиту от несанкционированого доступа к флеш-памяти, изменению температуры, тактовых сигналов, питания и других внешних воздействий,
модуль контроля циклическим избыточным кодом, который проверяет содержимое памяти и принимаемых/передаваемых данных,
а также сопроцессоры аппаратного шифрования(для тех применений, где необходима скорость) по различным алгоритмам
думаю, в приложениях где действительно нужна безопасность есть смысл использовать именно их!
Кажется, это первая относительно «взрослая статья» по микроконтроллерам на хабре!
от себя добавлю:
1 еще в качестве источникоа энтропии можно использовать встроенный датчик температуры (он обычно и делается не калиброваным)
2 некоторые контроллеры включают в себя защиту от несанкционированого доступа к флеш-памяти, изменению температуры, тактовых сигналов, питания и других внешних воздействий,
модуль контроля циклическим избыточным кодом, который проверяет содержимое памяти и принимаемых/передаваемых данных,
а также сопроцессоры аппаратного шифрования(для тех применений, где необходима скорость) по различным алгоритмам
думаю, в приложениях где действительно нужна безопасность есть смысл использовать именно их!
Да, про аппаратное шифрование упомянул. Проблема в том, что такие контроллеры — относительная редкость. Из того, что встречал, большинство семейств ориентированы на применение в смарт-картах, отсюда низкая универсальность, малое число выводов, мало полезной периферии… А криптография и защита от вторжения там да, на уровне!
отличная статья!
вот например, в бытовом компьютере zx-spectrum, чтобы очень быстро получить достаточно рандомное значение использовали регистр регенерации R, это простой 8-битный счетчик, который увеличивается каждый раз при выполнении цикла регенерации. насколько я знаю, такой прием можно использовать много где. (ведь, при генерации выскакивающих врагов особая рандомизация и не нужна, пожалуй, вообще достаточно таблицы =)
так же с sinclair basic была команда RANDOMIZE, которая задавала вектор рандомизации. в прошивке функция рандома была относительно простая и, насколько я помню, генерировала ответ на основе считывания прошивки. вот RANDOMIZE и задавал смещение от начала, как-то так.
подробней например, можно тут. www.worldofspectrum.org/ZXBasicManual/zxmanchap11.html
вот например, в бытовом компьютере zx-spectrum, чтобы очень быстро получить достаточно рандомное значение использовали регистр регенерации R, это простой 8-битный счетчик, который увеличивается каждый раз при выполнении цикла регенерации. насколько я знаю, такой прием можно использовать много где. (ведь, при генерации выскакивающих врагов особая рандомизация и не нужна, пожалуй, вообще достаточно таблицы =)
так же с sinclair basic была команда RANDOMIZE, которая задавала вектор рандомизации. в прошивке функция рандома была относительно простая и, насколько я помню, генерировала ответ на основе считывания прошивки. вот RANDOMIZE и задавал смещение от начала, как-то так.
подробней например, можно тут. www.worldofspectrum.org/ZXBasicManual/zxmanchap11.html
хорошие результаты еще дают сочетания регистр сдвига с линейной обратной связью и клеточного автомата
а что такое клеточный автомат?
Клеточный автомат это по сути набор ячеек, состояние каждой из которых задается определенным правилом и зависит от состояния соседних ячеек.
о, это как game of life получается!
ну да, чем то похоже, только в применение к генераторам ПСП поле игры будет одномерным. и в случае «умирания всей жизни» будет использована инжекция «живых клеток».
Получится ли реализовать клеточный автомат при приемлимых вычислительных затратах? Насколько понимаю, на каждом такте придется пробегать по всему регистру и модифицировать каждый бит, причем по довольно сложной логической формуле.
Видел два ГПСЧ на основе клеточного автомата.
первый описан здесь.
а второй — из математики — cellular automaton rule 90
Обоими можно поиграться в Randomness.
первый описан здесь.
а второй — из математики — cellular automaton rule 90
Обоими можно поиграться в Randomness.
Про «никогда больше не повторится» для 32-битного unix time — не совсем верно, если быть педантичным, в 2038 году он завернется (Y2K38 bug, аналогично более известному Y2K).
Хотя разумеется крайне маловероятно, что девайсина будет использоваться настолько долго, чтобы это было критично
Хотя разумеется крайне маловероятно, что девайсина будет использоваться настолько долго, чтобы это было критично
Отличная статья. Я разрабатываю методы исследования источников энтропии. Был бы рад провести тесты ваших контролеров.
У меня самого руки чешутся провести аппаратные тесты, все никак не доберусь до своих любимых железяк :)
Если вы проверите что-то из описанного на практике — буду только признателен.
Если вы проверите что-то из описанного на практике — буду только признателен.
Давно хочу поиграться с шумом стабилитронов.
Есть мнение что на качество шума отдельно взятого диода можно мистическим образом воздействовать.
Ибо теоретически, схема с одним шумистором питаемым источником ТОКа, была бы вполне эквивалентна схеме с двумя. Ведь нет статистической разницы между подкидыванием одной монеты, и двух…
Но старые перцы, говорят что де факто, она есть, и что-то смещает гаусово распределение.
В приведённой в статье схеме, это можно было объяснять плаваньем порога компаратора, и режима стабилитрона, но если использовать для его питания источник тока, то плавать ему некуда. И поэтому реально есть схемы с двумя шумелками, ибо даже мистические факторы, будут воздействовать на обе шумелки, и распределение вероятностей получится равномерным.
Есть мнение что на качество шума отдельно взятого диода можно мистическим образом воздействовать.
Ибо теоретически, схема с одним шумистором питаемым источником ТОКа, была бы вполне эквивалентна схеме с двумя. Ведь нет статистической разницы между подкидыванием одной монеты, и двух…
Но старые перцы, говорят что де факто, она есть, и что-то смещает гаусово распределение.
В приведённой в статье схеме, это можно было объяснять плаваньем порога компаратора, и режима стабилитрона, но если использовать для его питания источник тока, то плавать ему некуда. И поэтому реально есть схемы с двумя шумелками, ибо даже мистические факторы, будут воздействовать на обе шумелки, и распределение вероятностей получится равномерным.
Есть более простое объяснение, почему используют два диода. Даже забудем на время, откуда именно берется шумовой сигнал (обозначим напряжение шума Uш(t)). Нам нужно его оцифровать, для этого используется компаратор. Как работает компаратор? Если Uш > Uпорог, на выходе 1, если Uш < Uпорог, на выходе 0, все просто. Сложность в том, чтобы подобрать Uпорог так, чтобы 0 и 1 в полученной последовательности встречались с равной вероятностью.
А теперь возьмем два источника шума. На выходе компаратора будет 1, если Uш1 > Uш2, и 0, если Uш1 < Uш2. Если источники шума одинаковые, оба события равновероятны.
А теперь возьмем два источника шума. На выходе компаратора будет 1, если Uш1 > Uш2, и 0, если Uш1 < Uш2. Если источники шума одинаковые, оба события равновероятны.
Вы правы, по-хорошему, шумящий стабилитрон нужно питать от источника тока. Схема в статье предельно упрощена, просто для иллюстрации принципа. А бывают еще теплые ламповые генераторы шума, на спецальных лампах (вроде 2Д2С), специально для того предназначенных. При соблюдении режимов работы лампы она выдает шум со строго заданным заранее известным распределением.
Был бы рад применить ваши исследования источников энтропии в своем Randomness Framework =)
Sign up to leave a comment.
Генерация случайных чисел на микроконтроллерах