Можно ли использовать такие источники для кода сеанса?
На сайте был вопрос про альтернативные источники для создания кода сеанса:
http://www.cyberforum.ru/crypt.....y/thread1678074.html[link1]
Вместо использования аппаратного генератора СЧ, наподобие RdRand, предлагается использовать время запуска программы по системному времени UTC, время запуска программы ещё по времени работы ПК (высокоточный таймер), и номер текущего сеанса.
Аппаратный ГСЧ не устроил автора за его не повсеместное распространение и за внешнюю зависимость.
Всё это даёт 24 байта кода сеанса.
Утверждается, что он никогда не совпадёт в пределах того же ПК, если только время не откатится слишком сильно назад (превышающее время запуска ОС), и то вероятность совпадения всё также мала.
Для уникальности в пределах всех ПК было предложено добавить физический адрес сетевых карт, имени компьютера и другое, естественно пропустив это через хеш-функцию.
Нормально ли так делать? Первый вариант предлагает вообще не пропускать ничего через хеш-функцию, раскрывая системное время запуска программы и проработанное компьютером время на момент запуска программы.
Какая уважительная причина заставила автора заниматься столь унылым велосипедостроением вместо использования /dev/urandom?
Наверно желание самому контролировать процесс. Однако вещь довольно таки любопытная, и походу дела всё упирается в поддержание точного системного времени для теоретического несовпадения. Чтобы не было совпадений на разных ПК используется MAC адрес, но так ли физический адрес уникален, как считается?
То что это велосипедостроение было давно понятно, автору нравится это, вопрос лишь в том, как у него это получается.
Не совсем по теме, но есть вопрос.
Пытаюсь запустить точку доступа на debian7 с помощью hostapd. При попытке запуска происходит завис на том, что не хватает энтропии /dev/random. Где прописать чтобы обращение шло в /dev/urandom?
Почему бы тогда не подбрасывать монетку?
Он и не считается уникальным. В нём в лучшем случае 64 бита данных, значительная часть из которых вообще предсказуемы: идентификатор изготовителя, идентификатор типа и модели устройства и т.д. (Задача MAC-адреса в том, чтобы быть уникальным, а не случайным.) Но главное в том, что MAC-адрес не является сколь-нибудь секретным, он всегда передаётся в сеть и всегда в открытом виде.
Добавлю, и легко подменяем.
У автора выбор стоит, либо пропускать ключ, MAC адрес и время запуска программы по двум таймерам (utc, hightimer) через хеш-функцию, либо не пропускать, но если не пропускать через хеш, то смущает раскрытие посторонним время запуска и самого MAC адреса, так ли это страшно?, тем более что с приходом IPv6, где последние 64 бита – это и есть физический адрес, его раскрытие неизбежно.
Но повторюсь, у автора цель с помощью всего этого получить только лишь неповторимую числовую последовательность для кода сеанса.
Я например, даже не могу сказать, какой вариант мне больше нравится, так как пропускание всего этого через хеш может дать теоретическую коллизию, хотя наверно при достаточно большой длине это в принципе не должно волновать и может быть аргументом только в теории, но не в практике.
Автор решился и выбрал второй вариант, с небольшими изменениями:
ID – идентификатор юзера в случае многопользовательского подключения
Key – секретный ключ юзера
"1" – режим работы – генерация кода сеанса
PhysicalAddress[1...16] – физические MAC адреса (6 байт) шестнадцати и не более интерфейсов, если их меньше, оставшиеся байты массива остаются нулевыми.
TimeLaunch_UTC – время запуска программы по UTC
TimeLaunch_HighTimer – время запуска программы по высокоточному таймеру работы ПК
NumberSeance – номер текущего кода сеанса (инкремент +1)
Код сеанса равен как SHA-3-512(ID & Key & 1 & PhysicalAddress[1] & ... & PhysicalAddress[16] & TimeLaunch_UTC & TimeLaunch_HighTimer & NumberSeance).
Совпадения кодов сеанса начнутся после 2^256 сгенерированных кодов в пределах одного и того же юзера или же после 2^192 при вероятности 1 к 2^128 (2^(512-192*2)=2^128), что похоже успокоило автора.
Ну вобщем-то конечно способ достаточно интересный.
Как я понял, несколько MAC-адресов нужны, чтобы случайно не нарваться на неликвидный, как например у Teredo или других виртуальных адаптеров.
Автор ставит ошибочную дилемму. Нет никакой разницы, хэшируются входные данные ГПСЧ или нет, если сами входные данные предсказуемы или их можно достаточно быстро перебрать.
Что такое "код сеанса"? Nonce для криптопараметров? Или просто какой-то случайный идентификатор для сессии пользователя на веб-сайте?
Как я понял, это сделать не получиться, потому что на вход подаётся секретный ключ Key. Входные данные хешируются, потому что автор не хочет их раскрывать посторонним.
Как я понял, это просто идентификатор сессии, чтобы выходная гамма была каждый раз разной.
И мы возвращаемся к первому вопросу: зачем этот странный велосипед, если можно использовать стандартную конструкцию HMACk(R), где R — вывод из /dev/urandom?
Автору не нравится натуральный (аппаратный) ГСЧ вот почему:
1. Не везде он есть.
2. Внешняя зависимость, которая может сломать ГСЧ и он будет выдавать например одни единицы.
С другой стороны, достаточно мало кому нравится копаться в этом, обычно все используют всё стандартное, а здесь как видно спортивный интерес + любопытство. Ничего плохого я думаю нет.
Кстати, тема по ссылке в начале статьи всё ещё обсуждается на том форуме.
/dev/urandom – это ГПСЧ
Реальные временные метки – это не сильно далеко от единиц. А у автора-то есть какие-нибудь обоснования достоинств его велосипеда по сравнению со стандартными?
При чём здесь автор? Вопрос задаёте вы, а не автор. /dev/urandom — софтварный неблокируемый ГПСЧ, пополняемый из «хардварного» блокируемого /dev/random. Впрочем, насколько хардварен последний — не возьмусь судить. Матчасть была в комментариях [1][link2], [2][link3], смотрите по ссылкам.
В любой ОС он есть.
Уязвимость системного ГСЧ — настолько фатальная бага для настолько всего в системе, что целесообразно считать все велосипеды по её устранению заведомо бесполезными.
И это правильно. Стандартное хоть как-то худо-бедно обосновано, вылизано и проверено временем, в отличие от домашних велосипедов. Изобретать собственный ГСЧ — такое же фричество, как и делать собственный шифр или хэш.
Обезбаливающее можно купить в аптеке, ножики — в магазине, или сделать самим, а потом можно приступать к операциям на головном мозге. Все используют врачей и стандартных нейрохирургов, а здесь, как видно, спортивный интерес + любопытство. Ничего плохого, я думаю, нет.
Стойте, я совсем забыл, там речь вообще не о том, чтобы сделать свой ГСЧ, а получить каждый раз уникальные числовые последовательности, не обязательно не предсказуемые или секретные. Там связано с одноразовостью гаммы, а хеш берётся, чтобы скрыть MAC как минимум, вот в этом дело по сути получается.
Насколько мне известно, все аргументы сводятся к тому, что если взять все MAC-адреса на одном ПК, которых может быть и не один, плюс добавить метку utc запуска программы, ещё добавить время работы системы по высокоточному таймеру в момент запуска проги, и при каждом запросе в конце делать инкремент +1 номера сеанса, то вся эта вещь никогда не совпадёт.
Правда, там туманно указано, что время не должно сильно откатиться назад, больше чем время запуска ОС, потому что есть теоретическая вероятность нарваться на тоже UTC, но ведь значение высокоточного таймера всё-равно не совпадёт, если только всё это не произошло в тот же миг, отсчитывая от времени работы ПК.
А ещё на вход добавляется сам ключ, чтобы нельзя было подобрать входные известные параметры и узнать адреса сетевых карточек или тайм-метки.
Хотя на выходе смотрится даже как ГСЧ, но не в этом суть.
Я просто хочу понять, любопытно даже, почему это нельзя использовать то?
Тогда вообще непонятно, зачем этот велосипед с 7 колёсами и седлом, торчащим из руля. Автор может использовать один монотонный счётчик (нормальная подстраховка — дополнить счётчик системным таймером, но ничего сверх этого не нужно). Учитывая, что в схеме есть некий секретный ключ, это уже гарантирует неповторяемость между экземплярами приложения.
Это гарантирует неповторяемость в пределах одного ПК, но что если человек перенесёт свою учётную запись на другой ПК, а там например время отстаёт на 30 минут, и чтобы не нарваться на тоже значение utc и тоже значение высокоточного таймера (хоть это и маловероятно), MAC-адрес исправит ситуацию и не даст совпасть входным параметрам, а поскольку на компьютере несколько сетевых адаптеров, то проще взять сразу несколько, чтобы среди них оказался ликвидный, от физической карточки, а не от например Teredo.
А поскольку одного кода сеанса может не хватить, а постоянно делать запрос времени не лучший вариант, лучше один раз замерить время в момент запуска программы, и дальше делать инкремент счётчика текущего кода сеанса.
Вот всё это и отразил автор.
ID, Key – идентификатор пользователя и его ключ
PhysicalAddress[1...16] – сами MAC-адреса, чтобы обеспечить уникальность в пределах любых ПК
TimeLaunch_UTC – время запуска по UTC, он нужен, потому что высокоточный таймер повторяет свои значения при каждом запуске ПК
TimeLaunch_HighTimer – это нужно чтобы UTC не совпал, если запустить программу больше одного раза в 1 секунду, да и чтобы если время будет корректироваться автосинхронизацией в меньшую сторону, чтобы не дать совпасть, потому что время работы ПК не колеблеться.
NumberSeance – это чтобы не делать каждый раз запрос времени, а получать новые коды простым инкрементом, потому что если мы например сразу захотим получить 10 кодов сеанса, вдруг процессор успеет выдать несколько из них за один такт высокоточного таймера и будет совпадение.
Да, походу дела автор всё учёл до мелочей, мне сначала тоже казалось, что просто понапихано всего и вся.
Копипазжу актуальный вопрос:
Как не нарваться на "черный" MAC?
То что мы меняем mac-адреса, этим уже никого не удивишь. Но как можно проверять свежесгенерированный mac, чтобы он не оказался в списке совершенных из-под него тяжких преступлений (CP, fraud, terror e t.c.)? Как уже несколько раз бывало[link4], когда принимали людей, потому что они в Tor использовали IP через который до этого прошел криминал.
:)