Можно ли использовать такие источники для кода сеанса?


На сайте был вопрос про альтернативные источники для создания кода сеанса:
http://www.cyberforum.ru/crypt.....y/thread1678074.html[link1]

Вместо использования аппаратного генератора СЧ, наподобие RdRand, предлагается использовать время запуска программы по системному времени UTC, время запуска программы ещё по времени работы ПК (высокоточный таймер), и номер текущего сеанса.

Аппаратный ГСЧ не устроил автора за его не повсеместное распространение и за внешнюю зависимость.

Всё это даёт 24 байта кода сеанса.

Утверждается, что он никогда не совпадёт в пределах того же ПК, если только время не откатится слишком сильно назад (превышающее время запуска ОС), и то вероятность совпадения всё также мала.

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

Нормально ли так делать? Первый вариант предлагает вообще не пропускать ничего через хеш-функцию, раскрывая системное время запуска программы и проработанное компьютером время на момент запуска программы.

Комментарии
— SATtva (16/03/2016 09:40)   
Какая уважительная причина заставила автора заниматься столь унылым велосипедостроением вместо использования /dev/urandom?
— alexor1234 (16/03/2016 12:37, исправлен 16/03/2016 12:38)   
Какая уважительная причина заставила автора заниматься столь унылым велосипедостроением вместо использования /dev/urandom?

Наверно желание самому контролировать процесс. Однако вещь довольно таки любопытная, и походу дела всё упирается в поддержание точного системного времени для теоретического несовпадения. Чтобы не было совпадений на разных ПК используется MAC адрес, но так ли физический адрес уникален, как считается?
То что это велосипедостроение было давно понятно, автору нравится это, вопрос лишь в том, как у него это получается.

— гыук (16/03/2016 13:04, исправлен 16/03/2016 13:04)   

Не совсем по теме, но есть вопрос.
Пытаюсь запустить точку доступа на debian7 с помощью hostapd. При попытке запуска происходит завис на том, что не хватает энтропии /dev/random. Где прописать чтобы обращение шло в /dev/urandom?

— SATtva (17/03/2016 10:17)   

Почему бы тогда не подбрасывать монетку?


Он и не считается уникальным. В нём в лучшем случае 64 бита данных, значительная часть из которых вообще предсказуемы: идентификатор изготовителя, идентификатор типа и модели устройства и т.д. (Задача MAC-адреса в том, чтобы быть уникальным, а не случайным.) Но главное в том, что MAC-адрес не является сколь-нибудь секретным, он всегда передаётся в сеть и всегда в открытом виде.
— гыук (17/03/2016 13:09)   

Добавлю, и легко подменяем.
— alexor1234 (17/03/2016 14:20, исправлен 17/03/2016 14:29)   

У автора выбор стоит, либо пропускать ключ, MAC адрес и время запуска программы по двум таймерам (utc, hightimer) через хеш-функцию, либо не пропускать, но если не пропускать через хеш, то смущает раскрытие посторонним время запуска и самого MAC адреса, так ли это страшно?, тем более что с приходом IPv6, где последние 64 бита – это и есть физический адрес, его раскрытие неизбежно.
Но повторюсь, у автора цель с помощью всего этого получить только лишь неповторимую числовую последовательность для кода сеанса.
Я например, даже не могу сказать, какой вариант мне больше нравится, так как пропускание всего этого через хеш может дать теоретическую коллизию, хотя наверно при достаточно большой длине это в принципе не должно волновать и может быть аргументом только в теории, но не в практике.

— alexor1234 (18/03/2016 20:11, исправлен 19/03/2016 01:15)   

Автор решился и выбрал второй вариант, с небольшими изменениями:
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 или других виртуальных адаптеров.

— SATtva (19/03/2016 12:11)   

Автор ставит ошибочную дилемму. Нет никакой разницы, хэшируются входные данные ГПСЧ или нет, если сами входные данные предсказуемы или их можно достаточно быстро перебрать.


Что такое "код сеанса"? Nonce для криптопараметров? Или просто какой-то случайный идентификатор для сессии пользователя на веб-сайте?
— alexor1234 (19/03/2016 19:26, исправлен 19/03/2016 19:27)   
, если сами входные данные предсказуемы или их можно достаточно быстро перебрать.

Как я понял, это сделать не получиться, потому что на вход подаётся секретный ключ Key. Входные данные хешируются, потому что автор не хочет их раскрывать посторонним.


Что такое "код сеанса"? Nonce для криптопараметров? Или просто какой-то случайный идентификатор для сессии пользователя на веб-сайте?

Как я понял, это просто идентификатор сессии, чтобы выходная гамма была каждый раз разной.

— SATtva (20/03/2016 09:19)   

И мы возвращаемся к первому вопросу: зачем этот странный велосипед, если можно использовать стандартную конструкцию HMACk(R), где R — вывод из /dev/urandom?
— alexor1234 (20/03/2016 16:21, исправлен 20/03/2016 16:26)   
И мы возвращаемся к первому вопросу: зачем этот странный велосипед, если можно использовать стандартную конструкцию HMACk®, где R — вывод из /dev/urandom?

Автору не нравится натуральный (аппаратный) ГСЧ вот почему:
1. Не везде он есть.
2. Внешняя зависимость, которая может сломать ГСЧ и он будет выдавать например одни единицы.


С другой стороны, достаточно мало кому нравится копаться в этом, обычно все используют всё стандартное, а здесь как видно спортивный интерес + любопытство. Ничего плохого я думаю нет.


Кстати, тема по ссылке в начале статьи всё ещё обсуждается на том форуме.

— sentaus (20/03/2016 23:23)   
натуральный (аппаратный) ГСЧ

/dev/urandom – это ГПСЧ

он будет выдавать например одни единицы.

Реальные временные метки – это не сильно далеко от единиц. А у автора-то есть какие-нибудь обоснования достоинств его велосипеда по сравнению со стандартными?
— pgprubot (20/03/2016 23:25)   

При чём здесь автор? Вопрос задаёте вы, а не автор. /dev/urandomсофтварный неблокируемый ГПСЧ, пополняемый из «хардварного» блокируемого /dev/random. Впрочем, насколько хардварен последний — не возьмусь судить. Матчасть была в комментариях [1][link2], [2][link3], смотрите по ссылкам.


В любой ОС он есть.


Уязвимость системного ГСЧ — настолько фатальная бага для настолько всего в системе, что целесообразно считать все велосипеды по её устранению заведомо бесполезными.


И это правильно. Стандартное хоть как-то худо-бедно обосновано, вылизано и проверено временем, в отличие от домашних велосипедов. Изобретать собственный ГСЧ — такое же фричество, как и делать собственный шифр или хэш.


Обезбаливающее можно купить в аптеке, ножики — в магазине, или сделать самим, а потом можно приступать к операциям на головном мозге. Все используют врачей и стандартных нейрохирургов, а здесь, как видно, спортивный интерес + любопытство. Ничего плохого, я думаю, нет.
— alexor1234 (21/03/2016 00:31, исправлен 21/03/2016 00:45)   

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


Реальные временные метки – это не сильно далеко от единиц. А у автора-то есть какие-нибудь обоснования достоинств его велосипеда по сравнению со стандартными?

Насколько мне известно, все аргументы сводятся к тому, что если взять все MAC-адреса на одном ПК, которых может быть и не один, плюс добавить метку utc запуска программы, ещё добавить время работы системы по высокоточному таймеру в момент запуска проги, и при каждом запросе в конце делать инкремент +1 номера сеанса, то вся эта вещь никогда не совпадёт.
Правда, там туманно указано, что время не должно сильно откатиться назад, больше чем время запуска ОС, потому что есть теоретическая вероятность нарваться на тоже UTC, но ведь значение высокоточного таймера всё-равно не совпадёт, если только всё это не произошло в тот же миг, отсчитывая от времени работы ПК.


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


Хотя на выходе смотрится даже как ГСЧ, но не в этом суть.


Я просто хочу понять, любопытно даже, почему это нельзя использовать то?

— SATtva (21/03/2016 11:08)   

Тогда вообще непонятно, зачем этот велосипед с 7 колёсами и седлом, торчащим из руля. Автор может использовать один монотонный счётчик (нормальная подстраховка — дополнить счётчик системным таймером, но ничего сверх этого не нужно). Учитывая, что в схеме есть некий секретный ключ, это уже гарантирует неповторяемость между экземплярами приложения.
— alexor1234 (21/03/2016 15:04, исправлен 21/03/2016 15:13)   
Тогда вообще непонятно, зачем этот велосипед с 7 колёсами и седлом, торчащим из руля. Автор может использовать один монотонный счётчик (нормальная подстраховка — дополнить счётчик системным таймером, но ничего сверх этого не нужно). Учитывая, что в схеме есть некий секретный ключ, это уже гарантирует неповторяемость между экземплярами приложения.

Это гарантирует неповторяемость в пределах одного ПК, но что если человек перенесёт свою учётную запись на другой ПК, а там например время отстаёт на 30 минут, и чтобы не нарваться на тоже значение utc и тоже значение высокоточного таймера (хоть это и маловероятно), MAC-адрес исправит ситуацию и не даст совпасть входным параметрам, а поскольку на компьютере несколько сетевых адаптеров, то проще взять сразу несколько, чтобы среди них оказался ликвидный, от физической карточки, а не от например Teredo.


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


Вот всё это и отразил автор.


Код сеанса равен как SHA-3-512(ID & Key & 1 & PhysicalAddress[1] & ... & PhysicalAddress[16] & TimeLaunch_UTC & TimeLaunch_HighTimer & NumberSeance).

ID, Key – идентификатор пользователя и его ключ


PhysicalAddress[1...16] – сами MAC-адреса, чтобы обеспечить уникальность в пределах любых ПК


TimeLaunch_UTC – время запуска по UTC, он нужен, потому что высокоточный таймер повторяет свои значения при каждом запуске ПК


TimeLaunch_HighTimer – это нужно чтобы UTC не совпал, если запустить программу больше одного раза в 1 секунду, да и чтобы если время будет корректироваться автосинхронизацией в меньшую сторону, чтобы не дать совпасть, потому что время работы ПК не колеблеться.


NumberSeance – это чтобы не делать каждый раз запрос времени, а получать новые коды простым инкрементом, потому что если мы например сразу захотим получить 10 кодов сеанса, вдруг процессор успеет выдать несколько из них за один такт высокоточного таймера и будет совпадение.


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

— unknsecured (04/10/2018 09:29)   
Копипазжу актуальный вопрос:
Как не нарваться на "черный" MAC?
То что мы меняем mac-адреса, этим уже никого не удивишь. Но как можно проверять свежесгенерированный mac, чтобы он не оказался в списке совершенных из-под него тяжких преступлений (CP, fraud, terror e t.c.)? Как уже несколько раз бывало[link4], когда принимали людей, потому что они в Tor использовали IP через который до этого прошел криминал.
— zakhar77 (07/02/2019 12:52)   
:)

Ссылки
[link1] http://www.cyberforum.ru/cryptography/thread1678074.html

[link2] http://www.pgpru.com/comment89776

[link3] http://www.pgpru.com/comment87878

[link4] https://nl.livejournal.com/1385311.html