Аппаратные ГСЧ в ЦПУ от Intel

Судя по white papers (веб и file pdf, 457Kb) в 3-ем поколении ЦПУ i5 и i7 реализованы аппаратные ГСЧ/ГПСЧ соответствующие криптографическим критериям, расширенно множество инструкций – Intel Secure Key(codenamed Bull Mountain).
Так же приведен пример про простоту и легкость прикручивания их к OpenSSL с последующими кое-какими тестами производительности.
Есть уже у кого-нибудь опыт практического использования?

На страницу: 1, 2, 3, 4 След.

Комментарии

—	*Гость* (27/01/2013 18:47) <#>

Кто вам сказал, что закладка в ГСЧ всегда приводит к периоду?

К утечке по радио каналу приводит закладка.

—	unknown (27/01/2013 19:10) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Кто вам сказал, что в ГСЧ имеет смысл встраивать закладку, дающую утечку по какому-то каналу?

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

—	unknown (28/01/2013 21:13) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Мне одному кажется, что на сайте интела опечатка в схеме? В тексте везде CSPRNG, а на картинке какой-то CSPRING?

—	*Гость* (29/01/2013 13:33) <#>

CSPRING

Pseudo Random Intel Number Generator? :)

—	SATtva (29/01/2013 13:46) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

C-SPRING? Американцы любят аббревиатуры, складывающиеся в слова.

—	unknown (31/01/2013 09:58, исправлен 04/02/2013 11:12) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Приходят в голову два варианта тривиальной закладки в любой TRNG.

В генераторе есть схема, предназначенная для сбора энтропии (например из осцилляторов), но она там только для отвода глаз (на каких-нибудь рентгеновских или тепловых снимках будет видно, что она якобы есть и даже работает). Но её выход не будет ни к чему подключен. В генератор ставится замаскированный 256-битный счётчик. Основное его свойство: сколь угодно долго сохранять последнее значение своего состояния после выключения питания или любых воздействий (радиация, замораживание и т.д.) и никогда не сбоить. Это, кстати, инженерно сложная задача. Кроме того в процессор встраивается уникальный ключ шифрования значений счётчика.

Первый вариант. На производстве проца счётчик ставится в уникальное случайное значение C, оно нигде больше не запоминается. А вот уникальный прошитый ключ K запоминается в секретной базе производителя. В процессе имитации честной работы TRNG, счётчик делает цикл C+1 до 2²⁵⁶ и затем от 0 до C (сколько успеет за свой срок службы). Выход счётчика шифруется криптостойким алгоритмом с ключом K. При конфискации процессора на нём запускают этот FakeRNG и снимают два блока гаммы G 256+256 бит. К ним подбирают ключи из известных производителю K, которые расшифруют гамму с соблюдением условия Decrypt ( G1, G2 ) = ( C1, C1 + 1 mod 2²⁵⁶ ). Даже если был выпущен миллион процов, быстро перебрать миллион ключей несложно. Можно упростить задачу, привязав ключи к серийному номеру генератора (проца). И восстановить всё, что на нём когда-либо шифровалось, если использовался только этот RNG.

Второй вариант. Потенциально более "палевный" для производителя. Счётчик всем ставится в одинаковое (нулевое) состояние. Поскольку ключи у всех всё равно разные, то и гаммы будут всё равно вырабатываться разные. Тогда их можно будет подбирать удалённо, без доступа к процу. Например расшифровывать весь трафик, вычислять закрытые ключи по открытым и т.д.

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

—	*Гость* (03/02/2013 02:07) <#>

Без раскурочивания железа или взлома стойкого криптоалгоритма, доказать неслучайность чисел будет практически невозможно.

Будет очень смешно, если кто-то, имещюий доступ к этим секретам, потом сольёт эту информацию с мельчайшими подробностями, раструбит на весь мир и попросит политического убежища в Великой России. :) Пожалуй, это единственное, что не даёт кое-кому встраивать закладки на уровне железа.

—	ntldr (04/02/2013 00:36) профиль/связь <#> комментариев: 371 документов: 19 редакций: 20

Могут быть и более хитроумные варианты.

Имхо, закладка с персистентным счетчиком нереализуема из-за крайней сложности реализации персистентности счетчика — просто поставить десяток флэш-транзисторов там не получится. Более того, такую закладку можно легко обнаружить: достаточно создать набор условий для сбоя персистентного счетчика и смотреть корреляции между сессиями рандома. Для этого можно манипулировать питанием, облучать процессор рентгеном и т.д.

Я предлагаю другой вариант бэкдора:

Пусть последовательность, возвращаемая RNG, равна функции от серийнка процессора и 64-битного seed'а, прчём серийник и seed подмешиваются в саму последовательность¹, будучи размазанными в ней. Период 2⁶⁴ достаточен, чтобы его не обнаружить за разумное время². Имея часть последовательности и секретный алгоритм, атакующий может извлечь seed (благодаря его утечке) и вычислить всю последовательность. Если атакующему неизвестна даже часть последовательности, он всё равно может забрутить 2⁶⁴ вариантов на кластере; постороннему же обнаружить период не получится, т.к. ему неизвестен алгоритм генерации, а ждать завершения цикла нереально.

Расчет по скорости проявления цикличности таков: пусть период — 2⁶⁴, размер блока — 16 байт (как у AES), скорость генерации — 3 гигабайта в секунду (типичная для Intel RNG), тогда размер цикла равен 2⁶⁴⋅16=274877906944 гигабайт, период повторения — 91625968981 секунд ≈ 2905 лет. Значит, период можно еще уменьшить настолько, чтобы выходило лет 50 (для ускорения брутфорса атакующим). Аналогично, для 56-битного счетчика получится период повторения 11 лет, чего вполне достаточно, чтобы никто не смог обнаружить такой период³, т.е. для бэкдора хватит 56-битного сида.

Конечная архитектура бэкдора такова:

У каждого процессора есть серийный номер и 56-битный счетчик. При инициализации процессора счетчик заполняется рандомом:

выход RNG = f ( AES ( serial, counter ), serial, counter ),

где counter шифруется AES с ключом serial, а функция f подмешивает значения serial и counter в выходную последовательность. В этом бэкдоре две секретных части: серийник процессора, использующийся в качестве ключа (известен атакующему, неизвестен больше никому) и функция f, псевдослучайным образом подмешивающая значения счетчика и серийника в выходную последовательность. Зная функцию f, можно извлечь как serial, так и counter из последовательности и получить ее целиком: как вперед, так и назад. AES, кстати, тут не обязателен — достаточно одной хитрой функции f. Можно даже самому попытаться реализовать такое в железе. Единственный метод выявления — серьезный аппаратный реверс-инжиниринг.

Пояснения:

В этом бекдоре f — принципиально секретная часть, т.е. если f известна, можно извлечь serial и counter из гаммы напрямую⁴. И f можно упрятать так, что даже снятие топологии схемы под электронным микроскопом не позволит восстановить f. Например, f может быть построена на основе логической сети, в узлах которой находятся флеш-ячейки, тогда надо будет не только снять топологию, но и прочитать заряд каждой ячейки, сами же флеш-ячейки легко сделать разрушаемыми при травлении кристалла кислотами (такая защита применяется в микроконтроллерах). Есть и другие приемы аппаратной защиты. Учитывая уровень технологий изготовления современных процессоров, полноценный реверсинг мало кому по силам.

Ещё функция f может быть асиммитричной, например, на эллиптике⁵, в этом случае всё совсем замечательно — даже знание этой функции не дает постороннему похакать генератор. Правда, это усложняет бекдор, из-за чего его придётся делать программно-аппаратным: часть логики реализовывать на уровне микрокода, а часть — в виде схемы, но эта задача решаемая и не слишком сложная.

¹Естественно, псевдорандомным алгоритмом, известным только атакующему.
²Один процессор будет генерить всю последовательность 2905 лет — получить гамму быстрее, чем ее выдает процессор, не получится, т.к. для обнаружения периода придется ждать его проявления.
³Тем более, все сгенерированные данные за 11 лет надо хранить и как-то обрабатывать.
⁴Собственно, для того функция f и предназначена, чтобы была такая возможность.
⁵Подмешиваем зашифрованные эллиптикой seed и serial.

—	unknown (04/02/2013 10:31, исправлен 04/02/2013 10:37) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

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

"Размазать" гамму тоже просто — сгенерировать один случайный 256-битный блок, и каждый его бит вставить в последующие 255 блоков, которые являются функцией от этого первого случайного блока. Тогда и сохранять ничего не надо и при утере небольшой части блоков, можно подобрать недостающие биты. А можно использовать т.н. cryptcoding: криптостойкое и неотличимое от случайного "размазывание" меньшего в большее, основанное на смеси шифрования с кодированием избыточности или на разделении секрета. Но это не самый лучший способ восстановления.

Также не стоит завязываться на серийник процессора, тем более держать его в секрете и извлекать по какой-то секретной команде. Серийник может облегчать выбор ключа из базы, но поскольку число изделий ограничено, то можно просто перебрать из базы все их ключи. Это займёт мало времени: минуты, часы, максимум дни.

Можно вернуться к первому варианту, только использовать незаписываемый счётчик. При старте проца туда записывается настоящий рэндом и он инкрементируется с шифрованием выхода. И так до выключения питания, после чего стирается. При каждой перезагрузке всё повторяется заново. Это даже очень похоже на штатный алгоритм работы TRNG: в схеме практически ничего не надо менять, только слегка попортить — ключ с шифрованием якобы используются для отбеливания.

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

Через утечку дефектной энтропии из векторов инициализации, согласованиях параметров трафика в DH, можно будет много чего расшифровать. Не обязательно даже получать два подряд идущих чистых блока гаммы. Достаточно собирать все попадающиеся в пределах сеанса до предполагаемой перезагрузки и пытаться их расшифровывать известными ключами в (ECB-Counter)-режиме. При угадывании подходящего ключа из предопределённого набора между ними будет небольшое расстояние по счётчику (расстояния Хэмминга) в отличие от случайного распределения при неправильном ключе. Отсюда легко вычисляется счётчик сеанса.

Для распознавания разных сеансов составляются карты распределений блоков, к ним по быстрому подбирается своё значение счётчика и т.д.

Прикручивание асимметрики (эллиптики) не очень критично. Если сам факт бэкдора вскроется, то не так важно, смогут ли им воспользоваться посторонние. Данные всё равно будут считаться скомпрометированными обеими сторонами. К тому же, асимметрика, тем более эллиптика, требует кучу специальных заголовков, которые надо передать в определённом месте. И возможно, есть проблема распознаваемости. Так, например, протокол DH в эллиптике распознаваем от случайного значения (не является случайным оракулом), а стойкость достигается за счёт избыточности (не знаю подробностей ECC-Эль-Гамаля). Ну может его как-то ещё отбеливать можно, тожно не знаю эти тонкости, но ясно, что это всё ведёт к усложнению.

В то время как в симметричном шифровании случайного счётчика никаких векторов инициализации и заголовоков при данной задаче не обязательно. Каждый блок просто шифруется простой заменой без лишних вставок. И легко распознаётся простым перебором известных производителю ключей.

—	*Гость* (07/02/2013 07:28) <#>

Ваш последний варинт тоже жизнеспособный. Вообще, для бекдора в ГСЧ существует не одна единственная рабочая схема, можно много чего придумать.

Ещё подумалось, что короткий счетчик можно попытаться обнаружить через парадокс дней рождения: если счетчик имеет длину 64 бита и при старте заполняется случайно, вероятность получить коллизию имеется при 2³² стартах. Способ проверки на этот бэкдор такой: собираем стенд, который дергает питание на процессоре и генерирует по одному блоку случайных чисел за раз; повторяем это 2³² (или 2³³) раз, ищем коллизии.

—	unknown (07/02/2013 15:18) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

…Поэтому противник скорее всего будет использовать 256-битный счётчик и шифровать его, к примеру, 256-RIJNDAEL (который имеет 256-битовый блок, поэтому не вошёл в стандарт AES).

—	*Гость* (07/02/2013 19:44) <#>

От такого бекдора мало толку, ведь для его вскрытия нужно получить как минимум 1 блок рандома в неизменном виде, а это далеко не всюду возможно. Ну а короткий счетчик можно брутить повторяя алгоритм опирающийся на рандом, и таким образом вскрывать ssl сессии, pgp ключи, и вообще все что угодно. Поэтому я бы делал короткий счетчик, не длинее 64 бит (а лучше 56 бит чтобы не запариться брутить), и дополнил бы бекдор схемой которая вводит его в действие с задержкой в секунду (до этого на выход идет реальный рандом или псевдорандом). Таким образом сохраниться высокая универсальность бекдора, и проверка через парадокс дней рождения станет невозможной.

—	*Гость* (07/02/2013 20:33) <#>

http://habrahabr.ru/post/168607/ Извиняюсь что не в той теме. Важно.

—	*Гость* (08/02/2013 00:02) <#>

> http://habrahabr.ru/post/168607/ Извиняюсь что не в той теме. Важно.

У меня было такое, раз или два за 5 лет, что во время работы ноутбук сам выключился во время работы за ним без каких бы то ни было видимых причин, и дело не в батарее было. Мог ли быть глюк в самой ОС — не знаю.

—	*Гость* (22/05/2013 23:42) <#>

Странно, что по теме бэкдоров никто так и не вспомнил вариант с конечным множеством псевдослучайных последовательностей вообще не имеющих периода. Примерно такой же как и у спутников GPS. Вот только идентифицировать "вещающего" по совпадению с предварительно рассчитанным последовательностям будет отнюдь не маломощных чип за пятнадцать центов.

На страницу: 1, 2, 3, 4 След.

Ваша оценка документа [показать результаты]