Аппаратные ГСЧ в ЦПУ от Intel
Судя по white papers (веб и pdf, 457Kb) в 3-ем поколении ЦПУ i5 и i7 реализованы аппаратные ГСЧ/ГПСЧ соответствующие криптографическим критериям, расширенно множество инструкций – Intel Secure Key(codenamed Bull Mountain).
Так же приведен пример про простоту и легкость прикручивания их к OpenSSL с последующими кое-какими тестами производительности.
Есть уже у кого-нибудь опыт практического использования?
К утечке по радио каналу приводит закладка.
комментариев: 9796 документов: 488 редакций: 5664
Это к вопросу о том, что чисто алгоритмическая закладка может не иметь обнаружимого периода или вообще какого-либо различителя от случайного потока без знания секретного ключа.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Приходят в голову два варианта тривиальной закладки в любой TRNG.
В генераторе есть схема, предназначенная для сбора энтропии (например из осцилляторов), но она там только для отвода глаз (на каких-нибудь рентгеновских или тепловых снимках будет видно, что она якобы есть и даже работает). Но её выход не будет ни к чему подключен. В генератор ставится замаскированный 256-битный счётчик. Основное его свойство: сколь угодно долго сохранять последнее значение своего состояния после выключения питания или любых воздействий (радиация, замораживание и т.д.) и никогда не сбоить. Это, кстати, инженерно сложная задача. Кроме того в процессор встраивается уникальный ключ шифрования значений счётчика.
Первый вариант. На производстве проца счётчик ставится в уникальное случайное значение C, оно нигде больше не запоминается. А вот уникальный прошитый ключ K запоминается в секретной базе производителя. В процессе имитации честной работы TRNG, счётчик делает цикл C+1 до 2256 и затем от 0 до C (сколько успеет за свой срок службы). Выход счётчика шифруется криптостойким алгоритмом с ключом K. При конфискации процессора на нём запускают этот FakeRNG и снимают два блока гаммы G 256+256 бит. К ним подбирают ключи из известных производителю K, которые расшифруют гамму с соблюдением условия Decrypt ( G1, G2 ) = ( C1, C1 + 1 mod 2256 ). Даже если был выпущен миллион процов, быстро перебрать миллион ключей несложно. Можно упростить задачу, привязав ключи к серийному номеру генератора (проца). И восстановить всё, что на нём когда-либо шифровалось, если использовался только этот RNG.
Второй вариант. Потенциально более "палевный" для производителя. Счётчик всем ставится в одинаковое (нулевое) состояние. Поскольку ключи у всех всё равно разные, то и гаммы будут всё равно вырабатываться разные. Тогда их можно будет подбирать удалённо, без доступа к процу. Например расшифровывать весь трафик, вычислять закрытые ключи по открытым и т.д.
Могут быть и более хитроумные варианты. Без раскурочивания железа или взлома стойкого криптоалгоритма, доказать неслучайность чисел будет практически невозможно.
Будет очень смешно, если кто-то, имещюий доступ к этим секретам, потом сольёт эту информацию с мельчайшими подробностями, раструбит на весь мир и попросит политического убежища в Великой России. :) Пожалуй, это единственное, что не даёт кое-кому встраивать закладки на уровне железа.
комментариев: 371 документов: 19 редакций: 20
Имхо, закладка с персистентным счетчиком нереализуема из-за крайней сложности реализации персистентности счетчика — просто поставить десяток флэш-транзисторов там не получится. Более того, такую закладку можно легко обнаружить: достаточно создать набор условий для сбоя персистентного счетчика и смотреть корреляции между сессиями рандома. Для этого можно манипулировать питанием, облучать процессор рентгеном и т.д.
Я предлагаю другой вариант бэкдора:
Конечная архитектура бэкдора такова:
Пояснения:
1Естественно, псевдорандомным алгоритмом, известным только атакующему.
2Один процессор будет генерить всю последовательность 2905 лет — получить гамму быстрее, чем ее выдает процессор, не получится, т.к. для обнаружения периода придется ждать его проявления.
3Тем более, все сгенерированные данные за 11 лет надо хранить и как-то обрабатывать.
4Собственно, для того функция f и предназначена, чтобы была такая возможность.
5Подмешиваем зашифрованные эллиптикой seed и serial.
комментариев: 9796 документов: 488 редакций: 5664
Такой вариант имеет право на существование, но содержит много obscurity. В идеале, алгоритм бэкдора должен быть даже опубликован или разгадан, только без ключа это всё равно не давало бы его возможность обнаружить.
"Размазать" гамму тоже просто — сгенерировать один случайный 256-битный блок, и каждый его бит вставить в последующие 255 блоков, которые являются функцией от этого первого случайного блока. Тогда и сохранять ничего не надо и при утере небольшой части блоков, можно подобрать недостающие биты. А можно использовать т.н. cryptcoding: криптостойкое и неотличимое от случайного "размазывание" меньшего в большее, основанное на смеси шифрования с кодированием избыточности или на разделении секрета. Но это не самый лучший способ восстановления.
Также не стоит завязываться на серийник процессора, тем более держать его в секрете и извлекать по какой-то секретной команде. Серийник может облегчать выбор ключа из базы, но поскольку число изделий ограничено, то можно просто перебрать из базы все их ключи. Это займёт мало времени: минуты, часы, максимум дни.
Можно вернуться к первому варианту, только использовать незаписываемый счётчик. При старте проца туда записывается настоящий рэндом и он инкрементируется с шифрованием выхода. И так до выключения питания, после чего стирается. При каждой перезагрузке всё повторяется заново. Это даже очень похоже на штатный алгоритм работы TRNG: в схеме практически ничего не надо менять, только слегка попортить — ключ с шифрованием якобы используются для отбеливания.
Даже это даст противнику значительную утечку с сохранением неразличимости. Допустим, пользователь создал криптоконтейнер, заполнив его рэндомом из дефектного TRNG, а затем (не перезагружая компьютер) с помощью этого же TRNG создал ключ к этому контейнеру, который зашифровал своим паролем. Перебрав все блоки контейнера (среди которых найдутся незаполненные, т.е. чистая гамма) на попытку расшифровать известными ключами из них восстанавливается значение счётчика и искомый ключ. И это можно сделать даже не имея доступа к процу, не зная его серийника, а просто найдя неизвестно кем шифрованный контейнер на каком-нибудь файлхостинге.
Через утечку дефектной энтропии из векторов инициализации, согласованиях параметров трафика в DH, можно будет много чего расшифровать. Не обязательно даже получать два подряд идущих чистых блока гаммы. Достаточно собирать все попадающиеся в пределах сеанса до предполагаемой перезагрузки и пытаться их расшифровывать известными ключами в (ECB-Counter)-режиме. При угадывании подходящего ключа из предопределённого набора между ними будет небольшое расстояние по счётчику (расстояния Хэмминга) в отличие от случайного распределения при неправильном ключе. Отсюда легко вычисляется счётчик сеанса.
Для распознавания разных сеансов составляются карты распределений блоков, к ним по быстрому подбирается своё значение счётчика и т.д.
Прикручивание асимметрики (эллиптики) не очень критично. Если сам факт бэкдора вскроется, то не так важно, смогут ли им воспользоваться посторонние. Данные всё равно будут считаться скомпрометированными обеими сторонами. К тому же, асимметрика, тем более эллиптика, требует кучу специальных заголовков, которые надо передать в определённом месте. И возможно, есть проблема распознаваемости. Так, например, протокол DH в эллиптике распознаваем от случайного значения (не является случайным оракулом), а стойкость достигается за счёт избыточности (не знаю подробностей ECC-Эль-Гамаля). Ну может его как-то ещё отбеливать можно, тожно не знаю эти тонкости, но ясно, что это всё ведёт к усложнению.
В то время как в симметричном шифровании случайного счётчика никаких векторов инициализации и заголовоков при данной задаче не обязательно. Каждый блок просто шифруется простой заменой без лишних вставок. И легко распознаётся простым перебором известных производителю ключей.
Ещё подумалось, что короткий счетчик можно попытаться обнаружить через парадокс дней рождения: если счетчик имеет длину 64 бита и при старте заполняется случайно, вероятность получить коллизию имеется при 232 стартах. Способ проверки на этот бэкдор такой: собираем стенд, который дергает питание на процессоре и генерирует по одному блоку случайных чисел за раз; повторяем это 232 (или 233) раз, ищем коллизии.
комментариев: 9796 документов: 488 редакций: 5664
У меня было такое, раз или два за 5 лет, что во время работы ноутбук сам выключился во время работы за ним без каких бы то ни было видимых причин, и дело не в батарее было. Мог ли быть глюк в самой ОС — не знаю.