Русский
Русский
English
Статистика
Реклама

Криптография

B-Money история первой в мире криптовалюты

21.05.2021 16:09:34 | Автор: admin


31 октября 2008 года произошло событие, которое кардинально изменило всю привычную нам картину мира и оказало значительное влияние на экономику, развитие технологий и культуру. Именно в этот день никому не известный человек (или группа людей), скрывающийся под псевдонимом Сатоси Накамото, опубликовал статью Bitcoin: A Peer-to-Peer Electronic Cash System, положив начало истории биткойна. Однако еще за десятилетие до этого, в 1998 году, выпускник Вашингтонского университета Вэй Дай (Wei Dai) создал проект децентрализованной платежной системы, которая должна была использовать в своей работе криптографические алгоритмы. Даже называлась она похоже: B-Money.

Как закалялась сталь


О самом Вэй Дае американце китайского происхождения известно несколько больше, чем о легендарном Сатоси, но тоже немного. Он окончил Вашингтонский университет, получив степень бакалавра по информатике и математике. В профиле Вэй Дая, некогда размещенном на сайте несуществующей ныне компании VoteHere, говорилось, что он работал в составе исследовательской группы на корпорацию Microsoft в Редмонде, Вашингтон, где занимался криптографией. А до того как присоединиться к Microsoft, Вэй Дай трудился программистом в компании TerraSciences в Эктоне, Массачусетс. Это отчасти подтверждается и тем, что человек по имени Вэй Дай заявлен в качестве автора связанных с криптографическими технологиями изобретений согласно американским патентам 5724279 и 6081598, права на которые принадлежат Microsoft.


Вэй Дай получил степень бакалавра в Вашингтонскиом университете это немногое, что о нем известно достоверно.

Именно Вэй Дай является создателем криптографической библиотеки с открытым исходным кодом Crypto ++ (также известной как CryptoPP, libcrypto ++ и libcryptopp). Кроме того, в 2007 году совместно с Тедом Кровецем Вэй Дай разработал алгоритм универсального хеширования, послуживший основой для механизма аутентификации сообщений VMAC. Еще Вэй Дай первым обнаружил критическую уязвимость в криптографическом протоколе TLS (если говорить точнее в используемой TLS реализации режима шифрования Cipher Block Chaining (CBC)). Благодаря именно этой уязвимости стало возможным создание нашумевшего эксплоита BEAST (Browser Exploit Against SSL/TLS).

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

Однако вернемся к истории создания B-Money. Источником вдохновения для Вэй Дая по его собственным словам стала идеология криптоанархизма, которой он проникся благодаря текстам Тимоти Мэя. Криптоанархисты предрекали создание общества, свободного от какого-либо насилия прежде всего потому, что само по себе насилие невозможно, если членов социума нельзя идентифицировать благодаря повсеместному использованию криптографии.


Тимоти Мэй один из самых известных в мире шифропанков.

Однако любое общество нуждается во взаимных услугах, а следовательно, в инструментах для финансовых расчетов и заключения контрактов. Традиционные финансовые системы основаны на деньгах, эмитируемых либо самим государством, либо тесно связанными с ним банковскими структурами, и, следовательно, полностью контролируются правительством. Органы власти легко могут заблокировать любому неугодному человеку доступ к финансовым инструментам банковским счетам и картам, а также в состоянии заморозить или изъять его накопления, после чего гражданин фактически останется без средств к существованию. В противовес этому использующая криптографию анонимная и децентрализованная платежная система, независимая от каких-либо финансовых институтов, может гарантировать, что человек не потеряет возможность распоряжаться своими средствами по политическим, религиозным или каким-либо иным подобным мотивам.

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

Описная Вэй Даем идея в общих чертах сводится к следующему. Субъектами придуманной им платежной системы являются анонимные цифровые псевдонимы, которые никак не связаны с реальными личностями участников. Для поддержки работоспособности системы ее пользователи должны выполнять определенную вычислительную работу, за которую им выплачивается вознаграждение. Эта работа фиксируется в коллективном журнале с тем, чтобы ее могли проверить другие участники. В процессе аутентификации и подтверждения транзакций также применяется коллективный учет, при котором используется шифрование с открытыми ключами. Сам Вэй Дай писал: Протокол B-money был задуман таким образом, чтобы он мог сохранить конфиденциальность всех участников, оставаясь при этом средством обмена и предоставляя исполняемые контракты сообществу. Ничего не напоминает?

Фактически, Вэй Дай придумал архитектуру, очень похожую на современный блокчейн, хотя изначально им было предложено целых два протокола: один основывающийся на хранении базы транзакций локально у каждого пользователя платежной системы, в то время как второй гораздо больше напоминал блокчейн в том виде, в котором мы его знаем сейчас. Рассмотрим чуть подробнее оба проекта.

Концепция A-Money


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

Каждый пользователь системы идентифицируется цифровым псевдонимом. Все сообщения в системе подписываются открытым ключом отправителя и передаются получателю в зашифрованном виде. Любой участник системы может зарабатывать деньги, транслируя решение ранее нерешенной вычислительной задачи, при этом основным критерием оценки работы является объем вычислительных ресурсов, потраченных на решение. Для этого Вэй Дай решил использовать принцип, напоминающий способ вычисления индекса товарных цен (commodity price index). К примеру, если задача может быть решена на компьютере, который тратит на это минимум ресурсов, за 100 часов, а для покупки такого же вычислительного ресурса на открытом рынке потребуется 3 условных индексных единицы, то именно такая сумма в денежном эквиваленте и будет зачислена на счет решившего задачу участника системы, а информация об этом зафиксируется в локальных базах данных всех остальных пользователей.

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


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

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

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


Схема исполнения контракта в системе A-Money.

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

Концепция B-Money


Именно поэтому Вэй Дай предложил альтернативный протокол для своей платежной системы, который и получил название B-Money. Общий принцип остался тем же самым, только для хранения базы данных о транзакциях в B-Money использовались компьютеры не всех участников сети, а лишь некоторых. Машины таких хранителей Дай условно назвал серверами. В качестве образца для структуры этой сети Вэй Дай взял Usenet самую популярную на тот момент сеть для общения и обмена файлами. Формат широковещательных сообщений о любых операциях в системе B-Money был идентичен описанному выше, но с одним отличием: участники каждой транзакции должны в обязательном порядке убедиться, что сообщение было получено и успешно обработано случайно выбранным подмножеством серверов. Актуальность баз транзакций по задумке Дая должна поддерживаться их постоянной синхронизацией.

Однако в этом случае возникает проблема доверия серверам со стороны других участников системы. Вэй Дай решил ее следующим образом: каждый сервер должен депонировать определенную сумму цифровых денег на специальном счете. Если какой-либо из серверов оказывался замеченным в тех или иных мошеннических действиях, на него налагается штраф, который списывается с этого депозита. А участнику, заметившему мошенничество, с того же счета начисляется вознаграждение. Кроме того, хранящаяся на каждом из серверов база данных транзакций должна быть публичной, чтобы любой участник системы в любой момент времени мог проверить, совпадает ли локальная информация о состоянии его счета с записью в этой базе. Также любой участник по желанию должен иметь возможность убедиться, что общая сумма денег на всех счетах пользователей не превышает общую сумму цифровой валюты, которой оперирует платежная система. Это исключает возможность бесконтрольного наращивания денежной массы даже в случае сговора владельцев всех серверов в сети.


Общая структура B-Money.

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

1. Все держатели аккаунтов B-Money определяют по заданным алгоритмам оптимальный объем денежной массы, которую следует выпустить в следующем периоде. Неважно, придут ли участники системы к судьбоносному консенсусу, но каждый из них транслирует в сеть вычисленную им квоту. На основе полученных данных вырабатывается консолидированное решение об объеме цифровой валюты, выпускаемой в следующем периоде.
2. Каждый участник системы, желающий принять участие в эмиссии цифровой валюты, транслирует в сеть ставку в формате <X, Y>, где X сумма в B-Money, которую заявитель рассчитывает получить за решение задачи, а Y сама математическая задача, выбранная из пула ранее нерешенных задач. При этом каждая задача имеет публично согласованную номинальную стоимость в MIPS-годах.
3. Все участники системы выполняют работу согласно своим заявкам и транслируют в сеть полученные решения.
4. Из транслируемых решений принимаются и оплачиваются только имеющие самые выгодные ставки с точки зрения номинальной стоимости решенной задачи за единицу B-Money.

Можно сказать, что в 1998 году Вэй Дай придумал платежную систему, очень напоминающую хорошо знакомые нам современные криптовалюты. По крайней мере, она отвечает сразу нескольким критериям, по которым ее можно отнести к этой категории:
для ее добычи (майнинга) требуется выполнить определенный объем вычислительной работы;
проделанная работа проверяется другими участниками системы, а успешно выполнивший ее участник получает вознаграждение;
ведется коллективный учет транзакций, которые аутентифицируются с использованием криптографии;
контракты исполняются путем отправки широковещательных сообщений и подписания транзакций цифровыми подписями (криптография с открытым ключом).

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



Вместо эпилога


В своей основополагающей публикации Bitcoin: A Peer-to-Peer Electronic Cash System Сатоси Накамото все-таки сослался на проект B-Money это краткое упоминание на второй странице документа удостоилось единственной лаконичной сноски в разделе References. Однако в заметке Decoding the Enigma of Satoshi Nakamoto and the Birth of Bitcoin, опубликованной газетой New York Times 15 мая 2015 года, утверждалось, что Вэй Дай, а также известный британский криптографист и шифропанк Адам Бэк (Adam Back) были первыми людьми, с которыми связался Накомото в ходе работы над биткойном. Правда, сам Вэй Дай прокомментировал этот момент весьма скептически:

я так понимаю, что создатель биткойна [...] даже не прочитал мою статью, прежде чем сам заново изобрел эту идею. Он узнал об этом позже и упомянул меня в своей работе. Так что моя связь с проектом довольно ограничена.

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

Некоторые любители конспирологии всерьез считают, что однажды, когда тайна виртуальной личности Сатоси Накамото будет наконец раскрыта, среди создателей биткойна мы обнаружим немало известных личностей: и уже упомянутого Адама Бэка, и ученого-криптографиста Ника Сабо (Nick Szabo), но в первую очередь Вэй Дая собственной персоной. Кто знает, может, они окажутся правы?


Подробнее..

Музыкальная криптография

26.05.2021 18:20:11 | Автор: admin
Несколько столетий назад когда именно, доподлинно вряд ли известно, возник любопытный метод шифрования информации: с помощью нот. Точнее, с помощью их буквенного обозначения. Как вы знаете, ноты могут обозначаться не только классическими закорючками:


Но и буквами латинского алфавита: A, B, C и так далее. И когда-то, кому-то пришло в голову, что можно вставлять в музыкальные произведения, короткие последовательности нот, которые в буквенном выражении обозначают чьи-то инициалы или даже слова. Этот метод шифрования информации называется музыкальная монограмма.

Есть несколько подходов к созданию музыкальных монограмм. Например, слоговый: гласным буквам в тексте присваивали фонетически схожие названия нот. Считается, что в этом произведении Жоскен Депре, живший в 15-16 веках, закодировал нотами фразу laisse faire moy не мешай мне.

А если ставить ноты в соответствие не слогам, а буквам, то возникает другая проблема: буквенных обозначений нот от A до G не набирается на весь латинский алфавит. Сегодня её можно решить с помощью немецкого или французского методов.

Немецкий метод применялся ещё в 18 веке. Во-первых, у немцев иной порядок букв для обозначения нот: до-ре-ми-фа-соль-ля-си у них обозначаются как C, D, E, F, G, A, H. А во-вторых, недостающие буквенные обозначения они получали за счёт фонетического сходства: допустим, нота E могла кодировать как букву s, так и слог es. А в начале 20 века появился французский метод: одна нота могла кодировать сразу несколько букв алфавита в соответствии с простейшей таблицей (в шапке обозначения нот):


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

Здесь во вступлении нотами B-A-C-H закодирована фамилия Ивана Севастьяновича Баха:


Это не находка Листа, а дань уважения, Бах сам часто вставлял эту последовательность в свои произведения. К примеру, здесь:

Всего, на текущий момент, известно более 400 произведений с этой музыкальной монограммой.

Другой популярный пример: Шуман разбросал по всему своему Карнавалу нотную последовательность A-Es-C-H, которая обозначает его монограмму SCHA и название города ASCH, где он впервые влюбился.

Любопытный образец музыкального шифрования фраза берегись Лядова, записанная Николаем Мясковским в его Квартете для струнных No. 3: B, D, G, A, C, F = B, Re, Gis, La, Do, Fa. Лядов преподавал в Петербургской консерватории музыкальную композицию.

А в Сонате F-A-E, посвящённой скрипачу и композитору Йозефа Иоахиму, зашифрована фраза Frei aber einsam Свободен, но одинок:

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

P.S. Кстати, напоминаем про наш квест: https://royal.ruvds.com/.
Сегодня утром был перерезан второй провод и вероятность преждевременного падения рояля на ноутбук все выше. Сейчас его удерживают всего 3 троса, а тем временем победителя, который прошел бы квест и спас котика, все еще нет!

В эту пятницу 28 мая в 12.00 ноутбук будет залит жидким азотом и на него обрушится рояль массой 500 Кг.


Как подсказывают наши эксперты (главный инженер здания), пережить падение рояля ноутбуку будет очень непросто. Вернее, если дословно, то Петрович оценил ситуацию как ноутбуку ****ц.

Если вы находитесь в ступоре, то вот вам маленькая подсказка. Перечитайте пост выше и посмотрите на клавиши рояля на сайте




Подробнее..

Практическое руководство по анонимности в онлайне

18.05.2021 12:12:57 | Автор: admin

Направленная антенна для удалённого доступа к публичному Wi-Fi

Обеспечить собственную безопасность (анонимность) в онлайне тяжкий труд, требующий массивного объёма знаний. Даже лучшие профессионалы не всегда справляются.

Но это возможно.

Предупреждение. Для усвоения информации в полном объёме требуется несколько недель.

Пожалуй, наиболее полное практическое руководство по анонимности опубликовано на сайте Anonymous Planet. Оно периодически дополняется и актуализируется силами сообщества (текущая версия 0.9.3, см. историю изменений). Возможно, кто-нибудь возьмёт на себя поддержку русскоязычной версии, тем более в России и Беларуси эта информация становится с каждым годом всё актуальнее. Люди рискуют свободой и жизнью, не зная базовых вещей. В первую очередь это касается администраторов телеграм-каналов. Но и всех обычных пользователей, которые могут совершенно случайно попасть под раздачу.

Содержание



Общие приготовления


Создание анонимных цифровых личностей


Безопасное резервное копирование


Скрытие своих следов


Некоторые старые малотехнологичные трюки


Некоторые мысли по операционной безопасности

Если вы думаете, что вас раскрыли




Это настоящая энциклопедия анонимности. Хотя информация представлена в максимально лаконичном виде, документ весьма объёмный: около 563423 символов.


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

В то же время желательно продолжать использование старой (обычной) цифровой личности хотя бы периодически по стандартному паттерну, чтобы не вызывать подозрений.

Построение новой цифровой личности с нуля


Как указано в практическом руководстве, есть несколько путей достижения достойной анонимности. Это же касается и построения новой цифровой личности. Хотя во всех путях есть несколько общих шагов.

Можно поставить вопрос шире. Как создать совершенно новую личность не только в цифровом мире, но и в офлайне? Очевидно, что это гораздо более надёжный способ замести следы и избавиться от хвоста старых идентификаторов. Здесь требуется замена офлайновых документов и/или смена места жительства. Иногда достаточно просто временного переезда в деревню или в другую страну (так делают некоторые граждане, попавшие под административную или уголовную ответственность по политическим делам). Но эта тема достаточно хорошо раскрыта в литературе, так что сосредоточимся на создании новой цифровой личности.

Примерный порядок действий такой.

Наличные деньги


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

Покупка устройств


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

Вместо стандартного Gmail лучше зарегистрировать бесплатный аккаунт Protonmail. Нигде нельзя указывать личные данные или даты, в том числе в почтовом адресе, только псевдоним. Пароль из трёх-четырёх слов. Лучше запомнить его, а не записывать на листе бумаги. Менеджеры паролей отдельный разговор.

Далее можно поискать на барахолках типа Авито/Куфар хорошие смартфоны и ноутбуки. Например, смартфон Google Pixel 3a и ноутбук Lenovo Thinkpad. На барахолке можно сэкономить 250-300 долларов на телефоне и 450-500 долларов на ноутбуке, по сравнению с ценой нового устройства в магазине. Проверьте, что устройства в рабочем состоянии и с приличными характеристиками. Договоритесь с продавцом о подходящем времени встрече в общественном месте, чтобы совершить сделку, заплатите наличными.

Как только у нас появились устройства, пришло время поработать над ними.

Ноутбук


По всей вероятности, ноутбук придёт с Windows. Её придётся удалить. Можно пойти в ближайший торговый центр и купить USB-флэшку на 8 ГБ. В торговых центрах, как правило, также есть бесплатный Wi-Fi, поэтому идём на фудкорт, открываем ноутбук и скачиваем Pop!OS и Balena Etcher (это как один из вариантов: анонимный доступ можно обеспечить и на других дистрибутивах Linux: использование Windows в качестве основной операционной системы не рекомендуется, только в виртуальной машине). Делаем загрузочную флэшку помощью Pop!OS с помощью Balena Etcher. Устанавливаем Pop!OS на ноутбуке поверх Windows.

Телефон


Когда завершена установка Pop!OS на компьютере, возвращаемся на бесплатный Wi-Fi, загружаем CalyxOS и инструмент для прошивки. Используем последний для установки CalyxOS на Pixel 3a. При первой загрузке активируем MicroG опенсорсную реализацию гугловских библиотек. Она позволит использовать фейковый аккаунт Google для некоторых фоновых служб.



Достать биткоины


Теперь, когда мобильный телефон вступил в строй, пришло время установить на него биткоин-кошелёк. Например, Samourai Wallet. Можно записать на листе парольную фразу и 12 слов восстановления. Затем сходить на местную криптотусовку и найти, кто продаст биткоинов на 300 долларов. Монеты придут непосредственно в мобильное приложение Samourai Wallet.

Получить SIM-карту


Следующий шаг получить доступ к оператору мобильной связи и завести мобильный номер анонимным способом. Здесь тоже есть разные варианты. Например, за небольшую сумму настоящую SIM-карту зарегистрирует на себя бедный студент или другой малообеспеченный гражданин. Другой вариант использовать сервисы по анонимной продаже eSIM вроде silent.link. Покупаем eSIM и зачисляем кредит на счёт, оплатив его биткоинами. Импортируем eSIM в устройство Pixel 3a, и теперь у нас совершенно анонимный доступ к мобильной сети по всему миру.

Ни в коем случае не покупайте так называемые безопасные телефоны, не устанавливайте коммерческие анонимные мессенджеры и тому подобные сервисы вроде EncroChat и Sky ECC. Как показывает опыт, эти централизованные сервисы плохо кончают, выдавая в итоге всех пользователей и историю сообщений. Свою безопасность можно обеспечить только своими силами, и желательно опенсорсными инструментами.

Обновление домашней конфигурации


Эта часть предполагает, что у вас есть домашнее подключение к интернету. К сожалению, подключение к домашнему интернету требует подтверждения личности и оплаты через традиционные банковские системы, а не биткоины.

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

В России интернет-провайдер обязан хранить метаданные о вашем интернет-соединении в течение нескольких месяцев или лет. Это как минимум логи с указанием времени, когда вы посещали определённые веб-сайты.

При острой необходимости использовать домашний интернет (это практически невозможно сделать анонимно) желательно приобрести VPN типа Mullvad и оплатить биткоинами годовую подписку. Также купить маршрутизатор, на который можно установить прошивку типа pfSense. Система на маршрутизаторе настраивается таким образом, чтобы все устройства в домашней сети были защищены VPN.

На маршрутизаторе pfSense можно установить свой VPN-сервер, чтобы получить доступ к своей сети из любой точки мира.

В идеале работать через VPN/прокси на своём сервере на хостинге, оплаченном наличными или Monero. Список подходящих хостинг-провайдеров можно см. на сайте Monero.

Некоторые детали


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

Покупаем недорогой десктоп на барахолке, ставим Pop!_OS или другой любимый Linux-дистрибутив, создаём виртуальную машину Nextcloud и виртуальную машину Bitwardenrs для хостинга сервисов. Nextcloud будет хранить календарь, контакты, фотографии и другие документы. BitwardenRS будет менеджером паролей. Обязательно делайте резервные копии всей этой информации, сохраняя образы виртуальных машин на отдельном зашифрованном SSD/HDD или на нескольких накопителях, физически удалённых друг от друга для безопасности.

Далее можно подумать о настройке собственного биткоин-узла на компьютере с сервером Ubuntu, а также о майнинге или другом способе анонимного заработка криптовалюты. На сервере можно установить Bitcoin, Block Explorer, Samourai Wallet Dojo, Whirlpool, Lightning и BTCPay Server для приёма платежей. Здесь создаём новый кошелёк Samourai, соединяем его с Dojo и смешиваем монеты через миксер Whirlpool.


Миксер Whirlpool

Если у вас мало времени и нужно быстрое и простое решение, можно взглянуть в один из пакетов для Raspberry Pi myNode, Umbrel, Raspiblitz или Ronin.

Заключение


Чего лучше вообще никогда не делать, так это регистрироваться в Google, Facebook, Tiktok, WhatsApp или Instagram. Для общения в социальных сетях можно установить на своём хостинге инстанс Mastodon/Pleroma.

Не стоит нигде указывать реальный адрес электронной почты, лучше использовать алиасы типа simplelogin.io, одноразовые адреса Guerrilla Mail (сайт временно отключён хостером) или Getnada.

Везде по возможности лучше использовать бесплатный софт с открытым исходным кодом.

Конечно, это только один из путей по созданию новой цифровой личности и по анонимной работе в интернете. Более подробно о других вариантах см. в практическом руководстве Anonymous Planet.

И помните, что никакие советы не помогут сохранить анонимность, если вами заинтересуются действительно серьёзные ребята (типа АНБ/ФСБ/Моссад). Так что лучше соблюдать осторожность и не привлекать внимание.


Безопасность, xkcd

Замечания и дополнения приветствуются.



На правах рекламы


VDSina предлагает безопасные серверы в аренду с посуточной оплатой, возможностью установить любую операционную систему, каждый сервер подключён к интернет-каналу в 500 Мегабит и бесплатно защищён от DDoS-атак!

Подписывайтесь на наш чат в Telegram.

Подробнее..

Пришло время рассказать всю правду о взломе компании RSA

21.05.2021 12:08:14 | Автор: admin


У сотрудников компании RSA закончился десятилетний срок действия соглашений о неразглашении (NDA), так что они наконец-то смогли рассказать о событиях, которые случились в 2011 году. Эти события навсегда изменили ландшафт мировой индустрии информационной безопасности. А именно, это было первая в истории атака на цепочку поставок (supply chain attack), которая вызвала серьёзную обеспокоенность у американских спецслужб, мягко говоря.

Что такое атака на цепочку поставок? Если вы не можете напрямую атаковать сильного противника типа АНБ или ЦРУ, то вы находите их партнёра и внедряетесь в его продукт. Один такой взлом даёт доступ сразу в сотни серьёзно защищённых организаций. Так произошло недавно с SolarWinds. Но бывшие сотрудники компании RSA смотрят на SolarWinds и испытывают чувство дежавю. Ведь в 2011 году неизвестные хакеры получили доступ к самому ценному, что было в компании RSA хранилищу сидов (векторов генерации). Они используются для генерации кодов двухфакторной аутентификации в аппаратных токенах SecurID, а это десятки миллионов пользователей в правительственных и военных агентствах, оборонных подрядчиках, банках и бесчисленных корпорациях по всему миру.

Впрочем, обо всё по порядку.

Энди Гринсберг из журнала Wired поговорил с несколькими бывшими сотрудниками RSA. Один из них Тодд Литхэм (Todd Leetham), лысый и бородатый аналитик из отдела реагирования на инциденты, которого называли углеродной машиной для поиска хакеров. Именно он первым заподозрил неладное, обратив внимание, что один из пользователей вышел в сеть не со своего компьютера и с нестандартными правами. Он посмотрел логи этого юзера за несколько дней и стало понятно, что тут взлом. Хакеры окопались во внутренней сети.

Хуже всего, что они добрались до хранилища сидов. Технически, этот сервер должен быть в офлайне, отключён от интернета и от остальной сети защита air gap. Но на практике он был защищён файрволом и подключался каждые 15 минут, чтобы выдать новую порцию зашифрованных сидов, которые записывались на компакт-диски и отдавались клиентам. Затем они оставались в хранилище в виде резервной копии.

Исходя из этих векторов генерации происходила генерация кодов двухфакторной аутентификации на токенах SecurID, которые раздавались сотрудникам клиента. То есть и токен, и сервер RSA независимо друг от друга генерировали одинаковые коды.

Алгоритм получения токен-кода


Согласно стандарту SecurID, каждому токену соответствует 128-битное случайное число начальный вектор генерации (сид). Также в каждый токен встроены часы. Токен-код результат работы запатентованного компанией RSA алгоритма, который в качестве параметров берёт текущее время и начальный вектор генерации. По токен-коду невозможно восстановить начальный вектор генерации, так как алгоритм работает в одну сторону.

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

Если кто-то добрался до хранилища сидов, то это компрометировало токены SecurID у всех клиентов. Поскольку это основной бизнес RSA, то в худшем раскладе компанию вообще можно закрывать

Изучив сетевые логи, Литхэм пришёл к выводу, что эти ключи к королевству RSA действительно украдены.

Он с ужасом читал в логах, как хакеры девять часов методично выкачивали сиды из хранилища и отправляли их по FTP на взломанный сервер у облачного провайдера Rackspace. Но затем он заметил кое-что, что дало лучик надежды: в логах проскочили украденные креденшиалы, имя пользователя и пароль для этого взломанного сервера. Литхэм быстро подключился к удалённой машине Rackspace и ввёл украденные учётные данные. И вот оно: в директории на сервере всё ещё лежала вся украденная коллекция сидов в виде сжатого файла .rar.

Использовать взломанную учётку для входа на сервер, принадлежащий другой компании, и возиться с данными там, по признанию Литхэма, в лучшем случае является неортодоксальным шагом, а в худшем серьёзное нарушение законов США о несанкционированном доступе к информации. Но, глядя на украденную святая святых RSA на этом сервере Rackspace, он не колебался: Я был готов к последствиям, говорит он. В любом случае я не мог отдать наши файлы, и он ввёл команду на удаление файла и нажал Enter.

Через несколько мгновений в консоль пришёл ответ: Файл не найден. Он снова изучил содержимое сервера. Папка была пуста. Хакеры забрали базу с сервера за несколько секунд до того, как он попытался её удалить!

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


Расположение войсковой части 61398, источник

Через несколько дней RSA была вынуждена объявить о взломе. И это поистине изменило ландшафт кибербезопасности. Первая успешная атака на цепочку поставок, жертвами которой стали тысячи организаций, самые защищённые агентства и военные подрядчики. Только спустя десять лет случилось нечто подобное с червём NotPetya, а затем с системой компании SolarWinds (18000 клиентов по всему миру), но для того времени история RSA была беспрецедентной. Практически никто даже не предполагал, что можно проводить атаки таким образом через прокси в цепочке поставок.

Это открыло мне глаза на атаки типа supply chain, говорит Микко Хиппонен, главный научный сотрудник F-Secure, которая опубликовала независимый анализ инцидента RSA. И изменило мой взгляд на мир: если вы не можете проникнуть в цель, то находите технологию, которую использует жертва, и вместо этого проникаете туда.

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

Вопрос был вполне буквальным. Кража векторов генерации означала, что у тысяч клиентов RSA скомпрометирована критическая защита 2FA. После кражи векторов генерации злоумышленники могли вводить коды с токенов SecureID практически в любой системе.

Спустя десять лет закончился срок NDA у многих ключевых руководителей компании RSA и мы можем узнать подробности этого инцидента. Сегодня взлом RSA видится как предвестник нашей теперешней эры цифровой незащищённости и невероятной активности государственных хакеров во многих сферах общественной жизни, включая социальные сети, СМИ и политику. Взлом RSA это урок, как решительный противник может подорвать то, чему мы больше всего доверяем. А потому что не надо ничему доверять.

Анализ инцидента показал, с чего началась атака с невинного письма по электронной почте, которое получил один сотрудник австралийского подразделения, с темой План набора персонала на 2011 год и приложенной электронной таблицей Excel. Внутри был скрипт, который использовал 0day-уязвимость в Adobe Flash, устанавливая на компьютер жертвы хорошо известный троян Poison Ivy.

Точка входа в сеть RSA совершенно банальное внедрение, которое бы не сработало, если бы жертва работала под управлением более новой версии Windows или Microsoft Office или был ограничен доступ к установке программ на свой компьютер, как рекомендуют сисадмины во многих корпоративных и правительственных сетях.

Но после этого проникновения злоумышленники начали демонстрировать свои реальные способности. На самом деле аналитики пришли к выводу, что в сети одновременно орудовали по крайней мере две группы. Одна группа получила доступ в сеть, а вторая группа высококвалифицированных специалистов использовала этот доступ, возможно, без ведома первой группы. Вторая атака была гораздо более продвинутой.

На компьютере австралийского сотрудника кто-то использовал инструмент, который извлекает учётные данные из памяти. Затем он использует эти учётки для входа в другие машины. Потом сканируется память этих новых компьютеров в поисках новых учёток и так далее, пока не найдены логины привилегированных администраторов. В конце концов хакеры добрались до сервера, содержащего учётные данные сотен пользователей. Сегодня эта техника кражи учётных данных является распространённой. Но в 2011 году аналитики были удивлены, увидев, как хакеры продвигаются по всей сети: Это был действительно самый жестокий способ эксплойтить наши системы, который я когда-либо видел, говорит Билл Дуэйн (Bill Duane), опытный инженер-программист и разработчик алгоритмов RSA.

Обычно такие инциденты обнаруживают спустя месяцы после ухода хакеров. Но взлом 2011 года был особенным: в течение нескольких дней следователи, по сути, догнали хакеров и наблюдали за их действиями. Они пытались проникнуть в систему, мы обнаруживали их через минуту или две, и тогда отключали систему полностью или доступ к ней, говорит Дуэйн. Мы сражались неистово как звери, в реальном времени.

Именно в разгар этой лихорадочной схватки Литхэм поймал хакеров на краже сидов с центрального хранилища, что предположительно было их приоритетной целью. Вместо обычных подключений каждые 15 минут, Литхэм видел в логах тысячи непрерывных запросов каждую секунду. Хакеры собирали векторы генерации не на одном, а на трёх скомпрометированных серверах, передавая запросы через ещё одну подключённую машину. Они распределили коллекцию сидов на три части, перенесли их на удалённый сервер Rackspace, а затем объединили в полную базу хранилища RSA. Я подумал: это офигенно круто, говорит Литхэм. Я вроде как восхищался этим. Но в то же время понимал, что мы в полном дерьме.

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

Паника


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

На следующий день генеральный директор RSA Арт Ковиелло (Art Coviello) сделал публичное заявление о том, что взлом продолжается. Масштабы вторжения всё увеличивались по мере раскрытия новых деталей. О взломе хранилища сидов SecurID поначалу не было известно, но когда вскрылся этот факт, руководству нужно было принять решение. Некоторые советовали скрыть этот факт от клиентов (среди них спецслужбы, разведка, армия США). Но всё-таки решили раскрыть информацию персонально обзвонить каждого клиента и заменить все 40 с лишним миллионов токенов. Но у RSA и близко не было в наличии такого количества токенов Только через несколько недель компания сможет возобновить производство, и то в меньшем количестве.

Группа из почти 90 сотрудников RSA заняла конференц-зал и начала многонедельный обзвон всех клиентов. Они работали по сценарию, проводя клиентов через защитные меры, такие как добавление или удлинение PIN-кода как части логина SecurID, чтобы усложнить репликацию хакерами. Во многих случаях клиенты начинали орать, вспоминает Дэвид Кастиньола (David Castignola), бывший директор по продажам RSA в Северной Америке. Каждый сделал по сотне таких звонков, даже топ-менеджерам и руководству пришлось этим заниматься (клиенты встречались слишком важные).

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

На самом деле, к тому времени АНБ и ФБР уже прислали своих людей, чтобы расследованию компании, также как и оборонный подрядчик Northrop Grumman и компания по реагированию на инциденты Mandiant (по случайности, сотрудники Mandiant уже были на месте во время взлома, устанавливая сенсоры для системы безопасности в сети RSA).

Сотрудники RSA начали принимать решительные меры. Обеспокоенные тем, что телефонная система может быть скомпрометирована, компания сменила операторов связи, перейдя с AT&T на Verizon. Руководители не доверяли даже новым телефонам, они проводили личные встречи и передавали бумажные копии документов. ФБР, опасаясь крота в RSA из-за очевидного уровня знаний злоумышленников о системах компании, начало проверять биографические данные всех сотрудников.

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

Тем временем команда безопасности RSA и сторонние специалисты, привлечённые на помощь, начали разрушать здание до фундамента, как они выражались. На каждой машине, к которой прикасались хакеры, форматировались диски, и даже на соседних машинах. Мы физически обошли всё вокруг, и если на компьютере были хакеры, мы всё стирали, говорит Сэм Карри (Sam Curry), бывший директор по безопасности RSA. Если вы потеряли данные, очень жаль.

Вторая волна


В конце мая 2011 года, примерно через два месяца после объявления об инциденте, RSA всё ещё восстанавливалась и извинялась перед клиентами. Но здесь пошла вторая волна.

Влиятельный техноблогер Роберт Крингли опубликовал слухи о взломе крупного оборонного подрядчика из-за скомпрометированных токенов SecureID. Всем сотрудникам компании пришлось менять токены.

Спустя два дня агентство Reuters раскрыло имя взломанного подрядчика: это был Lockheed Martin, настоящая золотая жила для промышленного шпионажа.


Многофункциональный истребитель-бомбардировщик пятого поколения F-35 Lightning II производства Lockheed Martin

В последующие дни в новостях упоминались оборонные подрядчики Northrop Grumman и L-3 Communications, говорилось о хакерах с векторами генерации для токенов SecurID, хотя конкретных доказательств никто не предоставил, по понятным причинам, ведь речь идёт о военных подрядчиках (см. топ-100 подрядчиков правительства США).

Однако в июне 2011 года исполнительный директор RSA признал, что украденные сиды действительно использовались в атаке на Lockheed Martin. Спустя десять лет он уже отказывается от своих слов. Теперь бывшие руководители компании говорят, что использование сидов RSA никогда не было доказано.

Хотя в 2013 году представители Lockheed Martin на форуме Kaspersky Security Analyst Summit в Пуэрто-Рико подробно рассказали, как хакеры использовали векторы генерации кодов для токенов SecurID в качестве ступеньки для проникновения в сеть.

Сейчас источник в компании Lockheed Martin подтверждает выводы того расследования. По его словам, компания видела, как хакеры вводили коды SecurID в режиме реального времени, при этом пользователи не теряли свои токены. После замены этих токенов хакеры продолжали безуспешно вводить коды со старых токенов.

АНБ, со своей стороны, никогда особо не сомневалось в роли RSA в последующих взломах. На брифинге в Сенатском комитете по вооружённым силам через год после взлома директор АНБ генерал Кит Александер (Keith Alexander) заявил, что взлом RSA привёл к тому, что по крайней мере один американский оборонный подрядчик стал жертвой лиц, владеющих поддельными удостоверениями, а Министерство обороны было вынуждено заменить все токены RSA.

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

Дуэйн ушёл из RSA в 2015 году после более чем 20 лет работы в компании. Автор статьи в Wired Энди Гринберг задал ему такой вопрос: Как ты думаешь, в какой момент история со взломом RSA действительно закончилась: после отключения серверов в дата-центре? Или когда АНБ, ФБР, Mandiant и Northrop закончили расследование и ушли?. Инженер ответил: Мы считали, что атака никогда не закончилась. Мы знали, что они оставили бэкдоры и смогут проникнуть в сеть когда захотят.

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

Что касается Тодда Литхэма, то он наблюдал фиаско SolarWinds в течение последних шести месяцев с мрачным чувством дежавю. Выводы из истории RSA он формулирует в более резких выражениях, чем его коллега. По его мнению, это было редкое свидетельство того, как хрупка сегодня мировая система информационной безопасности: Это карточный домик перед началом торнадо, говорит он.

Он утверждает, что SolarWinds продемонстрировал, насколько ненадёжной остаётся эта структура. По мнению Литхэма, мир безопасности слепо доверял чему-то за пределами своей модели угроз. Никто не предполагал, что противник может это скомпрометировать. И вот опять противник вытащил карту, которая стояла в самом основании карточного домика, а все думали, что это твёрдая почва.
Подробнее..

Пиринговые мессенджеры враг государства?

24.05.2021 12:21:25 | Автор: admin


В случае полного отключения интернета одна из главных проблем общение с товарищами и родственниками. Опыт Гонконга показывает, что для этого хорошо подходят децентрализованные P2P-мессенджеры, которые работают без интернета, используя mesh-сеть по протоколам Wi-Fi Direct, Bluetooth, Apple Multipeer Connectivity Framework, ANT+, LoRa и др.

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

Вообще, вся история сетей wireless mesh намекает на то, что эта технология крайне не нравится правоохранительным органам.

Mesh-сети


Приложения типа FireChat создают mesh-сеть, используя Bluetooth и прямые подключения через Wi-Fi. Они обеспечивают обмен сообщениями и фотографиями в офлайне между устройствами, находящимися друг от друга на расстоянии примерно до 60 метров.

Все пользователи образуют единую сеть, которая расширяется с ростом количества устройств. На пути к получателю (получателям) сообщения передаются от одного устройства к другому.

Другими словами, вам достаточно приблизиться на 60 метров к ближайшему пользователю и вы можете отправить сообщение кому угодно. Каждый юзер нода в сети. Без интернета.

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

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

Особенно удобно, если каналы или комнаты в мессенджере создаются автоматически и объединяют людей, которые находятся рядом с друг другом (многоквартирный дом, стадион, концертный зал).

Для передачи текстовых сообщений можно приспособить практически любую mesh-сеть, даже сеть из геометок Apple AirTag, которые вообще-то предназначены не для общения людей, а для поиска утерянных вещей. В мае 2021 года хакерам удалось расшифровать трафик AirTag и передать по сети Apple Find My произвольный текст под видом оригинальных зашифрованных сообщений с GPS-координатами. Скорость передачи составила 3байта в секунду. Задержка в сети от 1 до 60 минут.



Подобные mesh-сети есть также у Samsung (Smart Things) и Amazon (Sidewalk) на протоколе LoRa. В принципе, можно использовать эту инфраструктуру для пирингового обмена сообщениями, а также для съёма данных с устройств вне зоны доступа в интернет.

Трагедия FireСhat


FireChat проприетарное приложение от американской компании Open Garden. Эта фирма прекратила дальнейшую разработку, не открыв исходники.

Последняя версия приложения: 9.0.14 (копия на 4pda) вышла полтора года назад (примечание: доступ к сайту 4pda затруднён с территории РФ).


FireChat

Первая версия FireChat появилась в марте 2014 года под iOS, в апреле под Android. Среди сооснователей Open Garden и разработчиков программы Станислав Шалунов и Грег Хазел из компании BitTorrent, где они делали торрент-клиент uTorrent (200 млн пользователей). Там и познакомились.

Вероятно, предприниматели рассчитывали, что FireСhat станет настолько же успешным, как файлоообменные P2P-приложения. Если представить себе эту картину, то весь мир может объединиться в mesh-сеть, а интернет становится практически не нужен! Даже хостинг сайтов теоретически можно размазать в распределённой сети. Такая фантазия.

Очень быстро FireСhat приобрёл популярность в Ираке после того, как местное правительство ввело ограничения на использование интернета, а затем то же самое произошло в Гонконге, во время массовых протестов 2014 года.


Главной проблемой FireСhat во время массовых протестов в Гонконге стала безопасность. Сама архитектура открытой mesh-сети предполагает, что все пользователи приложения светятся как радиомаячки на расстоянии 60 метров, а то и больше. Так что полиции отловить их было очень просто. Наличие программы на телефоне однозначно доказывало вину. Можно предположить, что сотни или тысячи пользователей были арестованы благодаря FireСhat. К тому же, в приложении не использовалось шифрование, так что никакие сообщения не были действительно приватными.

Возможно, критика от специалистов по ИБ повлияла на решение американской компании Open Garden прекратить разработку и не публиковать исходники. Ну или ребята увидели, что всемирная популярность торрентов им не светит, а развитие программы пошло совсем не по тому пути.

Когда появился FireСhat, это была единственная программа такого рода, которая позволяла пользователям создавать mеsh-сети в офлайновом режиме (без интернета) и обмениваться сообщениями1.

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


Фото из статьи FireChat мессенджер, на котором работают протесты в Гонконге, The Guardian

Тем более обидно, если FireСhat создавали специально для Гонконга, как разработку аналогичного приложения Commotion Wireless в 2011 году профинансировал госдепартамент США в преддверии Арабской весны. Хотели как лучше, а получилось как всегда

После FireСhat фирма Open Garden торговала электронными сим-картами (eSIM), продвигала свою криптовалюту, но в последние годы про неё ничего не слышно.

Вообще, приложение FireСhat было не очень качественным. Во-первых, закрытый код. Во-вторых, для регистрации обязательно (!) был нужен доступ в интернет, хотя потом оно работало в офлайне. Короче, странная программа. Может и хорошо, что разработчики её похоронили.

Рация Zello


Близкой по логике функционирования является интернет-рация Zello, которая заблокирована в Российской Федерации в апреле 2017 года.

Радио работает по принципу уоки-токи или push-to-talk. Основное преимущество возможность слушать голосовые сообщения по громкой связи в реал-тайме, вообще не притрагиваясь к смартфону и в то же время быть на связи с большим количеством пользователей.

Хотя здесь передаётся не текст/картинки, а звук, но принцип работы такой же через mesh-сеть, без интернета. Близкие друг к другу пользователи соединяются друг с другом напрямую и передают сообщения дальше, по цепочке. Что важно, здесь используется сквозное шифрование (E2E).

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

Это был первый прецедент, когда власти попытались сломать мессенджер, работающий по VPN. Понадобился целый год, чтобы заблокировать свыше 4тыс. IP-адресов из облака AWS, что не принесло успеха. Тогда РКН пошёл на шантаж компании Amazon, угрожая заблокировать 26 подсетей AWS, в сумме 13,5млн адресов.

Компания Amazon оказалась не готова к войне и отказалась предоставлять услуги Zello. Лишившийся облачной инфраструктуры сервис было легко заблокировать.

После успеха с блокировкой облачной VPN-инфраструктуры Zello, в 2018 году власти решили, что смогут успешно заблокировать такую же облачную инфраструктуру мессенджера Telegram. Но здесь нашла коса на камень: Павел Дуров инвестировал миллионы долларов в покупку всё новых и новых инстансов AWS, его брат Николай с коллегами запрограммировал систему обхода блокировок через прокси, а компании Amazon и Google выдержали блокировку своих подсетей в РФ. В итоге властям пришлось заблокировать 18 миллионов IP-адресов AWS и Google Cloud, что нарушило работу крупных ритейл-компаний, банков из топ-20, частных клиник и тысяч бизнесов в России. После двух лет выматывающей борьбы государство сдалось: руководителя Роскомнадзора уволили, Telegram разблокировали, а IP-адреса облачных сервисов удалили из чёрного списка.

Криптомессенджер Briar


Четыре года назад, в июле 2017 года, вышла первая публичная бета-версия мессенджера Briar, который работает через Tor или в офлайне, через пиринг. Его разработка продолжалась аж три года. Но продукт вышел на редкость качественный.

Это уже честный опенсорс. Приложение можно собрать из исходников (пошаговая инструкция для Android Studio). Оно доступно в каталогах приложений (например, Google Play) и отлично поддерживается: последняя версия 1.2.20 от 2апреля 2021года. Реализована стойкая криптография, сквозное шифрование.


По умолчанию мессенджер работает через интернет по протоколу Tor (луковичная маршрутизация). В этом случае программа создаёт на устройстве пользователя скрытый сервис Tor и соединяется со скрытыми сервисами Tor других людей из списка контактов. В случае отсутствия интернета она переходит на peer-to-peer коммуникации через Wi-Fi Direct, локальную сеть или Bluetooth.

Разумеется, при регистрации в криптомессенджере не требуется указывать номер телефона.

Поддерживает передачу сообщений (но не файлов), приватные группы, блоги/статусы и импорт RSS. Есть несколько полезных функций, таких как блокировка приложения (по PIN-коду).

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



Briar Project некоммерческий проект, который сейчас ведут шесть добровольцев. Код на 97,7% написан на Java (+немного Kotlin, Python и Ruby) и поставляется под GPLv3. Вскоре после первого релиза код прошёл независимый аудит безопасности от компании Cure53. Она известна своим аудитом проектов SecureDrop, Cryptocat и Dovecot. Так что Briar действительно надёжный вариант для пиринговых коммуникаций.

Единственный минус, что приложение выпущено только в версии под Android. Официальной версии для iOS нет и не будет, потому что эта платформа накладывает жёсткие ограничения на разработчиков, не позволяющие реализовать некоторые идеи P2P, и является закрытым проприетарным продуктом.

Но исходный код открыт, так что теоретически кто угодно может попробовать сделать стороннюю реализацию Briar под iOS, например.


Matrix, Riot, Element


Официальный клиент Element (бывший Riot) для относительно децентрализованной сети Matrix не поддерживает пиринговые коммуникации в офлайн-режиме и формирование mesh-сети.

В последнее время этот клиент получил некоторую известность. Сейчас количество пользователей Matrix/Element сравнимо с Briar или больше. У него есть сквозное шифрование, мосты в IRC, Slack, Telegram, Jitsi Meet и др. Но именно пиринга в офлайне нет.

См. также:


Secure Scuttlebutt p2p социальная сеть, работающая и в офлайне (есть клиент Manyverse для Android и iOS)

P. S. Кроме FireСhat, протестующие в Гонконге использовали малоизвестное мексиканское приложение Bridgefy, которое тоже умеет формировать mesh-сеть и передавать сообщения в офлайне. В октябре 2020 года приложение перешло на криптографический протокол Signal.

1 На самом деле ещё раньше были другие приложения, такие как Serval Mesh от проекта Serval Project или древний Commotion Wireless от Open Technology Initiative (с финансированием госдепа), но все эти разработки давно прекращены [вернуться]




На правах рекламы


Мощные виртуальные серверы на базе процессоров AMD EPYC для любых целей, в том числе для установки VPN.

Присоединяйтесь к нашему чату в Telegram.

Подробнее..

Честное онлайн-голосование миф или реальность?

27.05.2021 22:07:59 | Автор: admin

Привет, Хабр! Меня зовут Иван, я разрабатываю сервис онлайн-голосований WE.Vote на основе блокчейн-платформы Waves Enterprise. Сама идея голосований в онлайне уже давным-давно реализована разными компаниями, но в любых кейсах повышенной ответственности все равно прибегают к старой доброй бумаге. Давайте посмотрим, как электронное голосование сможет посостязаться с ней в максимально строгих условиях.

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

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

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

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

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

Стоит ли, положившись на идеальность нашего мира, отвечать на оба вопроса да? Или мы можем создать техническое решение, отвечающее всем требованиям?Давайте посмотрим.

Чего мы хотим добиться

На самом абстрактном уровне всё, что делают информационные системы, это создают/изменяют данные, передают данные, хранят данные, а также дают доступ к этим данным.В применении к онлайн-голосованиям это выглядит следующим образом:

  1. Организатор голосования создает повестку и хочет управлять правилами доступа к этой повестке: сделать ли ее публичной или раскрыть только участникам голосования.

  2. Организатор голосования создает список его участников и хочет быть уверенным, что в его голосовании примут участие именно они. Сами участники также заинтересованы в этом, так как подразумевается, что они принимают решение по важному для них вопросу и мнение/намерения/выгода третьих лиц не должны на это решение повлиять.

  3. Организатор задает правила проведения голосования. Эти правила без раскрытия сути голосования должны быть доступны широкой публике, чтобы организатор, участники голосования и третьи лица (например, регулятор) могли убедиться, что способ принятия решения был выбран корректно и все прошло по заранее известному плану.

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

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

  6. Организатор и участники голосования узнают его результаты. В этот момент все хотятбыть уверены,что никто не вмешивался в ход голосования, не фильтровал бюллетени, не делал вбросов, не подправлял итоги и т.п.. Все включая и оператора онлайн-сервиса голосований.

При чем тут блокчейн

Если бегло пробежаться по первому разделу, то единственной проблемой онлайн-голосований выглядит всевластие оператора сервиса голосования. Хорошая новость в том, что с появлением блокчейна мы научились ограничивать эту власть, разделяя ответственность за данные системы между ее участниками. Но очевидно, что блокчейн не являетсясеребряной пулей. По сути, это сравнительно медленная и капризная база данных инструмент, имеющий определенные положительные свойства и некоторые недостатки. Чтобы полностью решить задачу, необходимо правильно определить роль блокчейна в системе, понять,чего еще нам недостает.И кажется, у нас получилось сложить кусочки пазла посмотрим как.

Распределенное хранение

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

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

Естественно, встает вопрос хранения конфиденциальных данных. Блокчейнсам по себене позволяет таких фокусов, поэтому нам надо разобраться,какие данные в системе являются открытыми, а какие приватными. Атакженайти методы защиты конфиденциальных данных. Например, при создании голосования мы имеем следующий набор данных:

  • повестка и материалы голосования;

  • контактные данные пользователей идентификатор пользователей в реальном мире (e-mail или номер телефона);

  • персональные данные пользователей в целом, в системе не требуются, но делают работу удобнее как для организатора голосования, так и для самих участников;

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

С повесткой и материалами голосования мы можем работать как любой другой облачный сервис: организатор голосования загружает их на сервер (бэкенд), и их доступность определяется ролевой моделью: участникам голосования мы их показываем, от остальных прячем. Для уверенности в том, что на бэкенде ничего с повесткой не произойдет, сохраним в блокчейне хеш от материалов, хранящихся на сервере. Организатор видит, что в голосовании зафиксировано именно то содержание голосования, которое он планировал, участники голосования при получении повестки также могут убедиться, что повестка эта у всех едина.

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

Пара ключей создается пользователем локально, на его персональном устройстве. Приватный ключ этого устройства не покидает, а публичный сохраняется набэкендекак параметр учетной записи. Организатор голосования работает со списком участников в виде Ф.И.О. и e-mail. При сохранении данных голосования в блокчейне туда же уходит список публичных ключей. Голос подписан ключом пользователя, и если публичный ключ отправителя есть в списке участников, мы принимаем бюллетень. Такая схема позволяет,с одной стороны,не светить персональными данными пользователей, а с другой сделать более прозрачной работу системы.

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

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

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

Подводя промежуточный итог, можно сказать,что:

  • Мы решили проблему прозрачности и immutable-хранения исторических данных, используя блокчейн.

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

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

Но, несмотря на то что мы обещали обойтись без магии, она все-таки произошла. Для шифрования бюллетеней нам понадобился открытый ключ голосования, но никто не сказал, откуда он взялся! Очевидно, что это предельно важная часть всего процесса голосования и к нему нельзя отнестись легкомысленно. Еще более интересным кусочком пазла является приватный ключ, соответствующий открытому ключу голосования, так как именно с его помощью мы сможем получить итоги голосования.Настал момент шагнуть в область криптографии (которая для 99.9% людей не сильно отличается от магии).

Криптография

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

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

Несколько болеенадежным вариантом будет техника разделения приватного ключа после генерации хорошо известная схема разделения секрета Шамира. Ключевая пара создается, публичный ключ сохраняется в блокчейне как открытый ключ голосования, а приватный ключ разделяется на несколько частей, которые независимо хранятся доверенными участниками. Чтобы подвести итоги голосования, приватный ключ необходимо собрать и после этого расшифровать бюллетени. Если кто-то из доверенных участников заболел, схема Шамира предполагает возможность сбора приватного ключа меньшим количеством участников. То есть если ключ был разбит на N частей, собрать обратно его можно, используя K частей, где K < N.

Такой вариант выглядит гораздо более надежным и продвинутым, и это действительно так. Но есть нюансы. Во-первых, в промежуток времени между генерацией ключа и его разделением он является очевидной мишенью для злоумышленников и единой точкой отказа системы. Во-вторых, после сбора ключа мы получаем возможность расшифровать каждый индивидуальный бюллетень. Это не позволит нам их отфильтровать, так как они уже находятся в блокчейне и никуда оттуда не денутся. Но это позволит нарушить конфиденциальность голосования. На бэкенде есть связка Ф.И.О. и публичного ключа участника голосования, а в блокчейне связка публичного ключа и теперь уже расшифрованного бюллетеня. Мы знаем, как и кто проголосовал можем взять и, например, лишить премии неугодных.

Конечно, существуют механизмы разрыва первой связки персональных данных и открытого ключа через технику слепой подписи, но это очень своеобразный механизм, который необходимо правильно внедрить. При этом всё равно может сохраниться возможность вычислить по IP голосующего. Он приходит на авторизованный метод получать слепую подпись, а потом стучится на неавторизованный метод отправить голос. Формально во втором случае мы не знаем, кто именно к нам пришел, и опираемся только на проверку слепой подписи. Но у нас есть возможность сопоставить параметры устройства/браузера/соединения и понять, что это тот самый Иванов, который 5 минут назад получал у нас слепую подпись. Или представим похожую атаку на сопоставление по времени получения подписи и отправки голоса. Когда голосующие идут толпой по 500 человек в секунду, такая атака теряет свою эффективность, но при меньшей нагрузке вполне себе работает.

Попробуем сделать лучше?

Распределенная генерация ключа

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

Для формирования общегооткрытогоключа голосования (MainPubliсKey) используется алгоритм DKG (distributed key generation) из статьи TorbenPrydsPedersenA threshold cryptosystem without a trusted party,перенесенный на эллиптические кривые (в оригинальной статье используется мультипликативная группа конечного поля (поля Галуа)GF(p)). При этом есть ограничение:при любой жалобе (не сходится контрольная сумма) одного из участников на другого необходимо перезапустить процесс генерации с самого начала.

В нашей текущей реализации DKG используются стандартные эллиптические кривые seсp256k1 (Bitcoin, Ethereum) и функция хеширования SHA-256. Можно легко добавить, например, Ed25519 или даже российские кривые ТК-26 и хеш Стрибог, если потребуется. Также можно не завязываться на 256-битных кривых, а использовать 512-битные.

Участниками DKG у нас будут несколько экземпляров криптографических сервисов, выполняющих всю криптографическую магию. Чтобы не возникало вопросов о возможности непрозрачного общения между сервисами, единственным их интерфейсом будет взаимодействие с блокчейн-нодой. Один декрипт одна нода. Принципиально такое соотношение 1 к 1 не требуется, декриптов может быть больше или меньше чем нод, но выглядит логичным иметь одинаковый уровень децентрализации как на слое хранения/транспорта данных (см. раздел выше), так и на слое криптографии.

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

Протокол DKG Pedersen 91 на эллиптических кривых

Параметры протокола:

  1. Эллиптическая кривая E и генератор (Base) подгруппы этой кривой большого простого порядка q.

  2. Другой генератор (BaseCommit) той же подгруппы, для которого число x из соотношения BaseCommit = x * Base неизвестно никому.

  3. (k, n), гдеnобщее число развернутых криптографических сервисов (DecryptService), сгенерировавших пары ключей, аkминимальное число сервисов, которое необходимо для восстановления общего секрета. k <= (n+1)/2, то есть еслиk - 1участниковнечестные или у них украли ключи, то это никак не повлияет на безопасность общего секрета (MainPubliсKey).

Шаг 0. Индексы DecryptService

Каждому изnDecryptServiceприсваивается уникальный порядковый номер от 1 доn. Это нужно, потому что от порядкового номераDecryptServiceзависит коэффициент Лагранжа, который потребуется для реализации схемы K из N.

Шаг 1. Создание открытого ключа голосования

Каждый изnDecryptServiceгенерирует пару публичного (Pub_n)и приватного (priv_n) ключей для эллиптической кривой: j-йсервер генерирует пару ключей:priv_j,Pub_j,гдеPub_j = priv_j * Base(точка Base генератор простой подгруппы). И делает Pedersen commitment для публичного ключа:

  1. Генерируется случайное число, скалярr_j.

  2. Вычисляется точка, коммитС_j = r * BaseCommit + Pub_j.

  3. С_jпубликуется в блокчейн.

После того как каждый изnDecryptServiceопубликовал свой коммит ПедерсенаС_j, каждый DecryptService публикует свой скалярr_j. На основе опубликованных в блокчейне скаляров любой сторонний наблюдатель может восстановить публичные ключи каждого DecryptService Pub_j =С_j -r * BaseCommit а затем вычислить общий публичный ключ Pub (MainPublicKey) как сумму отдельныхPub_j.

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

Шаг 2. Генерация полиномов и раздача теней

Каждыйj-йDecryptService случайным образом:

  • Генерирует полином степениk - 1:f_j(x) = f_j_0 + f_j_1*x + ... + f_j_k-1* x^(k-1), где коэффициентf_j0 = priv_j, а остальные случайные элементы поляGF(q), гдеq порядок подгруппы точек.

  • Считает значения полинома для каждогоi-гоизnзначений:f_j(i) = f_j_0+ f_j_1*i + ... + f_j_k-1* i^(k-1). Значениеf_j(i)называется тенью (shadow).

  • Шифруетf_j(i)при помощиPub_iдля всех других серверов и публикует результаты шифрования. Таким образом,значениеf_j(i)может узнать только владелецpriv_i, т.е. DecryptService номерi.

Шаг 3. Проверка коэффициентов полиномов

Чтобы убедиться, что каждый из DecryptService следует протоколу DKG, они проверяют значения теней, полученных друг от друга. Каждый DecryptServiceпубликует каждый коэффициент своего полинома, умноженного на генератор Base: j-й сервер:fj,0* Base, fj,1* Base, ... , fj,k-1* Base, где fj,k-1 это коэффициент при степениk - 1.

После этого каждыйi-йDecryptServiceпроверяет все расшифрованные тениf_j(i)(гдеjиз множества от 1 доn, исключаяi), которые для него зашифровали другиеn - 1участников DKG. i-йDecryptServiceдля тени от сервераj:

  1. Вычисляетf_j(i) * Base

  2. Берет экспоненты его коэффициентов:fj,0* Base, fj.1* Base, ... , fj,k-1* Base

  3. Домножает каждый на соответствующую степеньi:fj,0* Base, i * ( fj,1* Base), ... , i^(k-1) * ( fj,k-1* Base)

  4. Складывает их.

Если результат сложения равенf_j(i) * Base(тень отjдляi, умноженная на генератор), то результат принимается. В противном случае публикуется жалоба на серверj: значение тениf_j(i), и протокол запускается с самого начала шага 0.

Если ни у кого нет жалоб, то каждый сервер вычисляет свой секретный ключs_iкак сумму значенийf_j(i)от всехjсерверов, включая себя.

Если взять любые изkучастников, то сложив ихs_i * Lagrange(k, i), где Lagrange(k, i) коэффициент Лагранжа, который зависит от номеров из выбранной группы (k) и номераi, мы получим приватный ключ, соответствующий общему ключу Pub (MainPublicKey), то есть по сути сумму всехpriv_i.

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

Мы решили проблему угона приватного ключа до начала голосования. Он не был создан централизовано, и чтобы получить доступ к данным голосования, злоумышленнику необходимо взломать K серверов, а не один. Но остается вопрос: как мы будем проводить расшифровывание. Будем ли мы собирать приватный ключ в этот момент и дадим ли шанс злоумышленнику? Пожалуй, не дадим.

Шаг 4. Распределенное дешифрование

Допустим, мы зашифровываем сообщение M на открытом ключе голосования (MainPublicKey):

  1. Генерируем число r и считаем R = r * Base.

  2. ВычисляемС = M + r *MainPublicKey.

  3. Получившийся шифротекст пара точек (R, C) мы публикуем в блокчейне.

  4. Владелец приватного ключаprivвычисляет значение:priv * R.

  5. И расшифровываетM:M = С -priv * R.

Таким образом, для расшифровывания (R, C) нужно вычислитьpriv * R.

Если наш приватный ключ распределен (допустим, что (k, n) = (3,6)), каждый криптографический сервис независимо считает значениеs_i * R, используя свою часть приватного ключа, и публикует результат в блокчейне. Назовем это значение частичной расшифровкой. Дальше остается домножить любые 3 из 6 результатовs_i * Rна соответствующий коэффициент Лагранжа, сложить три точки и получить priv * R. А используя это значение, мы расшифровываем сообщение М.

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

Гомоморфное шифрование

Теперь у нас есть неплохой наборинструментов:мы защитили исторические данные (блокчейн), мы умеем создавать ключи шифрования и расшифрования без единой точки отказа (DKG), умеем пользоваться этими ключами прозрачным образом, также не имеющим единого слабого звена. Оба инструмента опираются на общую идеологию децентрализации, где мы не вынуждены доверять единому оператору системы, а можем положиться на нескольких независимых участников.

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

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

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

Бюллетень в виде матрицы вопросов и вариантов ответовБюллетень в виде матрицы вопросов и вариантов ответов

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

Подсчет результатов в зашифрованном видеПодсчет результатов в зашифрованном виде

В итоге мы получаем не только совместную и прозрачную работу нескольких независимых сервисов при вычислении итогов голосования, где ни один из них не может эти результаты подтасовать. Мы также добились очень высокого уровня конфиденциальности голосования. Мы анонимизировали выбор участников голосования через сложение столбиком у нас есть сумма, но нам неизвестны слагаемые!

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

Зашифрованное сообщение 1: ( R1, С1 ) =( r1 * Base,M1 + r1 *MainPublicKey)

Зашифрованное сообщение 2: ( R2, С2 ) =( r2 * Base,M2 + r2 *MainPublicKey)

Их сумма: ( R1 + R2, C1 + C2 ) = ( ( r1+r2 ) * Base, M1 + M2 + ( r1 + r2 ) *MainPublicKey)

Сумму расшифровываем так же, как отдельные сообщения (помним чтоMainPublicKey= priv * Base):

( M1 + M2 ) = ( C1 + C2 ) priv * ( R1 + R2 ) = M1 + M2 + ( r1 + r2 ) *MainPublicKey priv * ( r1 + r2 ) * Base = M1 + M2

Кто-то скажет магия, кто-то возразит математика.

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

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

Доказательства с нулевым разглашением (ZKP Zero Knowledge Proofs)

Однако не только организатор или внешний злоумышленник могут иметь мотивацию повлиять на исход выборов. Нарушитель может затесаться и в ряды участников голосования. Поскольку мы используем очень простую механику сложения столбиком и не заглядываем в индивидуальные бюллетени, у участника голосования есть возможность покопаться в клиентском приложении и сформировать бюллетень, где он вместо "1" проставит за своего кандидата значение 100500. Или 100500 за того, кого недолюбливает. Система посчитает итоги, и кандидат нарушителя победит с внушительным преимуществом.

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

Одна из самых наглядных демонстраций работы ZKP (интерактивной разновидности) это Пещера Али-Бабы или Лабиринт:

Участник A обладает ключом, открывающим дверь в лабиринте, и хочет доказать это участнику B, но не хочет показывать ключ. Чтобы В мог убедиться в верности утверждения А, они организуют серию испытаний:

  1. А заходит в лабиринт пока В отвернулся. В не знает, в какую сторону пошел А.

  2. В дает А указание выйти с какой-либо стороны, например, слева.

  3. Если А действительно обладает ключом, он может появиться с любой стороны и выполняет указание В.

Шанс того, что А просто повезло, и он, не имея ключа, изначально пошел налево, составляет 50/50. Поэтому они повторяют испытание еще и еще раз, пока вероятность везения не станет пренебрежимо малой, и В не признает, что А действительно обладает ключом. При этом В не увидит самого ключа, не получит никакой информации, которой обладает А (направление, которое А выбирает в каждом испытании), но в результате серии испытаний он получит достоверное (вероятностное, но с любой необходимой В точностью) доказательство.

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

ZKP на бюллетене

По каждому вопросу мы, помимо заполненных и зашифрованных ячеек с вариантами выбора, к каждой ячейке приложим NIZK, доказывающее, что в этой ячейке зашифровано одно из значений 0 или 1 но не раскрывающее, какое именно. И дополнительно приложим доказательство, что зашифрованная сумма значений всех ячеек по вопросу равна 1. Это означает, что участник голосования может поставить 1 в любую из ячеек и выбрать только один вариант.

При желании (а оно у нас есть) мы можем на базе этой схемы ZKP реализовать более сложные схемы голосований. Например, взвешенное голосование, где каждый участник отдает не один голос, а количество голосов, пропорциональное своей доле акций компании. Для этого мы должны вместо 1 создать ZKP для значения веса голоса участника. Или вариант голосования с множественным выбором, где каждый голосующий может выбрать не один вариант из N, а несколько. Для этого мы по каждой ячейке добавляем ZKP для ряда значений [0, 1, 2, 3]. Суммарный ZKP может быть на значение [3] тогда голосующий должен распределить все свои голоса. Или на ряд значений[1, 2, 3] то есть он может выбрать от 1 до 3 вариантов, но не может не ответить на вопрос.

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

Структура зашифрованного бюллетеня выглядит следующим образом:

(R_1, C_1), Proof_1,

.........................

(R_M, C_M), Proof_M,

Sum_Proof

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

ZKP на частичных расшифровках

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

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

Второе условие: если расшифровывание нескладывается,и мы подозреваем, что некоторые криптографические сервисы решили саботировать голосование, неплохо бы иметь возможность проверить, какой именно из сервисов сбоит. Для этого при публикации частичных расшифровок каждый криптосервис создает и прикладывает ZK-доказательство расшифровки, используя алгоритмZKP Chaum-Pedersen, который доказывает знание числа x для двух соотношений A = x * B и C = x * D (где A B, C, D точки на одной кривой).

Теперь у любого квалифицированного стороннего наблюдателя есть возможность:

  • самостоятельно провести гомоморфное сложение валидных бюллетеней и получить итоговый бюллетень;

  • проверить доказательства расшифровки этого суммарного бюллетеня от каждого криптографического сервиса;

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

Для удобства последний шаг мы проведем сами и зафиксируем итоги голосования в блокчейне как массива массивов вида [ [ 2,5,6 ], [ 3,5,5 ], [ 7,6 ], [ 10,3 ] ].

Смарт-контракты

Фух, кажется, мы описали протокол голосования, который, используя распределенные технологии и криптографию, позволяет дать честным участникам и организаторам голосований все необходимые гарантии и защищает процесс коллективного принятия решений от внутреннего и внешнего нарушителя. Очевидно, при условии правильной децентрализации распределении узлов системы между независимыми участниками; без этого мы получаем замороченные Google Forms :)

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

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

А что дальше?

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

Еще одно важное для нас направление развития то, о чем разработчики, увлеченные красивым решением технической проблемы, склонны забывать. А именно UX опыт пользователя :)Прикрутить блокчейн это современно, модно,и в данном случае даже целесообразно, но попробуйте пользователю, который привык к UX современных мобильных и веб-приложений, объяснить, что такое его персональный приватный ключ и что без него он не сможет сделать в системе ровным счетом ничего.Или дать ему одновременно гарантию, что отправленная им транзакция будет принята системой, не заставляя ждать его, пока мы сами в этом убедимся. Нода майнит, прелоадер крутится, пользователь ждет и не понимает чего именно: Ну не знаю, почту я отправляю, все работает мгновенно, а тут чего-то ждать надо?. Поэтому мы активно работаем над тем, чтобы система сохраняла привычные пользовательские свойства, не теряя своих технологических преимуществ.

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

Каждое из этих направлений развития это множество нетривиальных и разноплановых задач, которые совершенно точно не дают нам скучать.Надеюсь, вам было интересно. Буду рад ответить в комментариях на вопросы по статье.

Подробнее..

Транспортный протокол QUIC приняли в качестве стандарта RFC 9000

01.06.2021 02:22:59 | Автор: admin


QUIC новый транспортный протокол связи, который отличается уменьшенным временем задержки, большей надёжностью и безопасностью, чем широко используемый сегодня TCP (RFC 793).

Уже много рассказывалось о преимуществах транспорта QUIC, который взят за основу будущего стандарта HTTP/3. В HTTP следующего поколения транспорт TCP меняется на QUIC, что означает автоматическое ускорение соединений и зашифровку всего интернет-трафика, который раньше шёл в открытом виде по TCP. Нешифрованный QUIC не предусмотрен вообще.

В мае 2021 года состоялось знаменательное событие: протокол QUIC принят в качестве официального стандарта RFC9000. Это великолепные новости для всей интернет-экосистемы.

Утверждением таких стандартов занимается Инженерный совет Интернета (IETF). Ранее были оформлены вспомогательные стандарты RFC 9001, RFC 9002 и RFC 8999.

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

В последние годы QUIC был одним из главных приоритетов IETF. Появившись как эксперимент Google, вскоре разработка QUIC вышла на международный уровень. Она велась почти пять лет. Зафиксировано 26 очных собраний, 1749 задач в трекере и многие тысячи писем в почтовой рассылке.

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

Окостенение означает, что система с каждым годом становится всё менее гибкой, менее подвижной. QUIC принесёт в транспортный уровень множество инноваций, включая обязательное шифрование, версионность, гораздо более богатый и более производительный набор сервисов, поверх которых будут строиться новые технологии. Предполагается, что QUIC приведёт к появлению нового поколения интернет-инноваций. Это уже начало происходит с расширениями, такими как ненадёжные датаграммы (Unreliable Datagram Extension). Ненадёжные датаграммы открывают двери перед новым классом медиа в реальном времени и другими приложениями, которым нужен более функциональный транспорт, чем обязательная доставка пакетов с обрывом канала при потере нескольких пикселей. Мы уже видим многообещающие технологии, такие как MASQUE и WebTransport.

HTTP/3


Стандарт HTTP/3 (это HTTP поверх QUIC) идёт с небольшим опозданием за QUIC и тоже будет официально принят в самое ближайшее время.


34-й (!) драфт HTTP/3

С момента принятия HTTP/2 прошло шесть лет: спецификация RFC 7540 опубликована в мае 2015-го, но пока не используется повсеместно. Протокол реализован во всех браузерах ещё с конца 2015 года, а спустя три года только 45,4% из 10 млн самых популярных интернет-сайтов поддерживают HTTP/2. Два с половиной года назад таких было 31,2%. Севсем недавно на HTTP/2 перешли сайты Amazon, Paypal, Telegram.org.

Cейчас практически готова третья версия HTTP/3, осталось совсем немного подождать.

QUIC представляет собой замену TCP, которая работает поверх UDP. Изначально эта технология была создана инженерами Google, как и предыдущий протокол SPDY, который стал основой HTTP/2. В первое время QUIC именовали HTTP/2-encrypted-over-UDP.

Затем разработку QUIC передали в IETF для стандартизации. Здесь он разделилcя на две части: транспорт и HTTP. Идея в том, что транспортный протокол можно использовать также для передачи других данных, а не только эксклюзивно для HTTP или HTTP-подобных протоколов. Однако название осталось таким же: QUIC. Разработкой транспортного протокола занимается рабочая группа QUIC Working Group в IETF.

Долгое время версия IETF называлась iQUIC, в то время как Google и другие продолжили работу над собственной реализацией gQUIC, но 7 ноября 2018 года один из ведущих разработчиков протокола Дмитрий Тихонов объявил, что стороны достигли совместимости протоколов, и теперь разработка продолжится в общем русле. QUIC в Chrome включается в настройках chrome://flags. Есть ещё расширение-индикатор, которое показывает, какие сайты поддерживают QUIC.



Встроенная безопасность и производительность


В чём преимущества транспортного протокола QUIC перед TCP? Преимуществ очень много. По словам руководителя рабочей группы Марка Ноттингема, переход от устаревшего TCP на новые протоколы просто неизбежен, поскольку сейчас очевидно, что TCP страдает от проблем неэффективности.

Поскольку TCP протокол доставки пакетов по порядку, то потеря одного пакета может помешать доставке приложению последующих пакетов из буфера. В мультиплексированном протоколе это может привести к большой потере производительности, объясняет Марк Ноттингем. QUIC пытается решить эту проблему с помощью эффективной перестройки семантики TCP (вместе с некоторыми аспектами потоковой модели HTTP/2) поверх UDP.

Кроме перехода значительного объёма трафика с TCP на UDP, протокол QUIC требует обязательного шифрования: нешифрованного QUIC не существует вообще. QUIC использует TLS 1.3 для установки ключей сессии, а затем шифрования каждого пакета. Но поскольку он основан на UDP, значительная часть информации о сессии и метаданных, открытых в TCP, шифруется в QUIC.



В статье Будущее интернет-протоколов Марк Ноттингем говорит о значительных улучшениях в безопасности с переходом на QUIC:

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

Кроме того, становится невозможна пассивная оценка RTT и потерь пакетов путём простого наблюдения за соединением; там недостаточно информации для этого.

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

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

Возможно, принятие стандарта QUIC произошло бы и раньше, если бы компания Google не поспешила внедрить свою реализацию в браузер Chrome, так что случилось раздвоение стандарта.

Тем не менее, прогресс неизбежен и в ближайшие годы обязательно продолжится стандартизация и повсеместное внедрение различных протоколов нового поколения, в том числе HTTP/3 на транспорте QUIC.



См. также:





Отмечайте юбилей GlobalSign и получайте скидки!


Подробнее..

Свой криптографический протокол опасная идея

01.06.2021 12:20:22 | Автор: admin

Разработка своей криптографии в чём-то сравнима с созданием собственного авиадвигателя, говорит эксперт по безопасности Руна Сандвик. Фото: Виталий Кузьмин

Предположим, заказчик требует разработать собственный сетевой протокол. Например, для передачи данных между сервером и мобильным приложением, для связи между микросервисами, модулями программной системы, поверх UDP или поверх TCP. С шифрованием.

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

Это распространённые причины, из-за которых разрабатывают проприетарные протоколы.

Безопасность


Поговорим о безопасности.

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

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

Например, важной частью бизнеса многих компаний является сервис и техническое обслуживание. Поэтому некая компания, скажем, системный интегратор предпочтёт вместо стандартных Open Source решений внедрить клиенту проприетарный софт с собственным закрытым протоколом. И всё. После этого она будет доить клиента десятилетиями.

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

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

Но жизнь иногда показывает обратное. А именно:

  1. Принцип безопасность через неясность не работает. Любой протокол можно отреверсить.
  2. Проприетарная реализация шифрования это очень рискованно.
  3. Никто не поможет закрыть критические дыры в закрытом софте.

Принцип безопасность через неясность не работает в криптографии


Принцип безопасность через неясность (security through obscurity) заключается в том, чтобы скрыть внутреннее устройство системы или реализацию для обеспечения безопасности.

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

Сравните с опенсорсными системами, где разработчик специально открывает код, чтобы независимые сторонние эксперты помогли выявить и исправить эти недостатки.

В итоге получается, что собственный проприетарный протокол, максимально закрытый от посторонних глаз и обфусцированный, вовсе не увеличивает безопасность системы, а уменьшает её!


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

Голландский криптограф Огюст Керкгоффс изложил правила проектирования военных шифров в книге Военная криптография (1883). Основная идея была в том, что попадание системы в руки врага не должно причинять неудобств. Поэтому ничего, кроме ключа, не должно быть секретным.

Собственная криптография


Вопрос Почему не разработать собственную криптографию? чем-то похож на вопрос Почему не спроектировать авиадвигатель?, говорит Руна Сандвик, исследователь по безопасности. Конечно, теоретически мы можем это сделать. Но это чрезвычайно сложно. Гораздо более простой и надёжный вариант выбрать готовое решение, проверенные и надёжные протоколы и алгоритмы.

Поэтому в сообществе информационной безопасности вызывает большое подозрение, если какая-то компания реализует собственный проприетарный протокол. Например, проприетарный протокол MTProto в Telegram поначалу вызвал массу критических отзывов. Взлом MTProto1.0 стал одной из самых популярных статей на Хабре в 2013 году: Безопасен ли Telegram? Или как я искал закладку в MTProto (спойлер: глупые ошибки в проприетарной криптографии).

Хотя баг быстро исправили, это наглядный пример, почему не нужно разрабатывать собственные авиадвигатели криптографические алгоритмы. Вы можете допустить ошибку а риски огромные. Люди полагаются на безопасное шифрование, от этого зависит их свобода, а иногда жизнь.

К тому же, в мессенджере запрещена анонимная регистрация без номера телефона вероятно, так удобнее коммерческой компании, чтобы блокировать спам и продвигать приложение по адресным книгам. Кто будет думать об анонимности, когда на кону миллиарды долларов прибыли? При этом Telegram изначально позиционировали именно как безопасный мессенджер (многие пользователи купились на такую рекламу).

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

Привязка к телефонному номеру делает пользователя уязвимым, потому что операторы сотовой связи внутри страны удобный объект для работы спецслужб.

Конечно, в опенсорсе есть свои специфические риски. Например, проблемы с сотнями зависимостей, которые вы не контролируете. Например, 20% багов в проектах на GitHub явно внесены в проекты специально, со злым умыслом. То есть вредоносными контрибуторами, которые действовали умышленно. Ещё не забыта история c мейнтейнером ESLint, который 12 июля 2018 года опубликовал вредоносные версии пакетов eslint-scope и eslint-config-eslint в репозитории npm.

Такое может случиться с каждым опенсорсным проектом, потому что мейнтейнеры работают бесплатно, на износ:


Поэтому иногда соглашаются продать свой проект (такая же история с расширениями для браузеров). А этот проект уже внедрён в качестве зависимости в тысячи других.

Но все проблемы безопасности решаемы. Независимый аудит открытого кода профессиональными экспертами лучшая гарантия его надёжности.

Кстати, в 2013 году проприетарный софт впервые обогнал опенсорсные проекты по среднему количеству багов на 1000 строк кода.


Источник: Coverity Scan Open Source Report

В прошлом веке считалось, что проприетарный софт пишут профессионалы, а Open Source любители. Сегодня же профессиональный уровень опенсорсных программ вовсе не уступает проприетарным. Может, даже превосходит их.

Возвращаясь к примеру Telegram. 5 декабря 2020 года двое итальянских математиков Марино Микулан и Никола Витоколонна опубликовали на сайте препринтов arXiv.org исследование Автоматическая символическая проверка протокола MTProto 2.0 в Telegram (вторая версия опубликована 30 апреля 2021 года, arXiv:2012.03141v1). Оно подтверждает безопасность обновлённой версии фирменного протокола MTProto 2.0.


Набор протоколов MTProto 2.0 (в голубой рамке) и область покрытия данной научной работы (светло-зелёным цветом). Схема из научной статьи Марино Микулана и Никола Витоколонны, arXiv:2012.03141v1

Статья содержит полностью автоматизированное доказательство надёжности аутентификации MTProto 2.0, обычного чата, зашифрованного end-to-end чата и механизмов повторного ввода ключей в отношении нескольких свойств безопасности, включая аутентификацию, целостность, конфиденциальность и совершенную прямую секретность, а также доказывает формальную корректность MTProto 2.0.


Протокол аутентификации MTProto 2.0. Здесь $\{m\}_{pk}$ означает асимметричное шифрование $m$ открытым ключом $pk$. В свою очередь, $\{m\}_{(k,iv)}$ означает симметричное шифрование общим ключом $k$ с вектором инициализации $iv$. Схема из научной статьи


Слегка упрощённая версия протокола MTProto 2.0 для секретных чатов. Все сообщения перенаправляются через сервер $S$: каждое сообщение между $X \in \{A, B \}$ и $S$ шифруется с использованием ключа авторизации $X$ (здесь не показан). Обратите внимание, что $g_{ab}$, $k$ и $iv$ не известны серверу $S$. Схема из научной статьи



Эта математическая работа чуть ослабила озабоченность экспертов по поводу проприетарного протокола MTProto2.0. Редкий случай, когда собственная нестандартная криптографическая система (пока) работает надёжно. В ней ещё не нашли таких фатальных уязвимостей, как в MTProto 1.0.

Неужели разработчики Telegram всё-таки научились и смогли сделать уникальный авиадвигатель без ошибок? Можно только порадоваться за них, ведь все пользователи Telegram участвовали в этом обучении как бета-тестеры. В каком-то смысле это наш общий успех.



На правах рекламы


Наша компания предлагает серверы с Linux или Windows. Не экономим на железе только современное оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить!

Присоединяйтесь к нашему чату в Telegram.

Подробнее..

Taidoor мультитул для хакера

03.06.2021 14:23:54 | Автор: admin


Автор: Иннокентий Сенновский


Taidoor крайне эффективная вредоносная программа класса RAT (remote access trojan), предназначенная для использования без закрепления в системе. Модульная система, реализованная в Taidoor, отличается от многих других RAT гибкостью: операторы программы могут отправлять на зараженную систему только те модули, которые нужны для достижения целей конкретной атаки.


Чтобы затруднить обнаружение, Taidoor использует несколько разных методов: манипуляции с временными метками, удаление файлов с модулями, обфускацию строк, поиск антивируса на атакуемой машине и др.


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


Источник информации о зараженной системе, включая имена файлов, отчет агентства кибербезопасности и безопасности инфраструктуры США (CISA) номер AR20-216A.


Taidoor в арсенале злоумышленника


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


Два встроенных модуля позволяют собирать информацию о зараженной системе. По мере необходимости с сервера управления можно отправлять дополнительные модули.


В ходе общения с управляющим сервером Taidoor использует криптоконверт RSA + AES для обеспечения конфиденциальности. Однако криптография в программе реализована слабо: при перехвате трафика можно подменить команды от сервера. Также при использовании указанного алгоритма на сервере может появиться уязвимость, позволяющая расшифровать отправляемые на сервер данные, к которым удалось получить доступ.


Загрузчики Taidoor


Загрузчики основного тела Taidoor файлы rasautoex.dll и ml.dll, идентичные по функциональности. Они отличаются только разрядностью: первый является 64-битной версией малвари, второй 32-битной. Их свойства представлены в табл. 1.


Табл. 1. Свойства загрузчиков Taidoor


Свойства 64-битная версия 32-битная версия
Имя файла rasautoex.dll ml.dll
Тип файла PE32+ Executable (DLL) PE32 Executable (DLL)
Класс ВПО Загрузчик (Loader) Загрузчик (Loader)
MD5 4ec8e16d426a4aaa57c454c58f447c1e 6aa08fed32263c052006d977a124ed7b
SHA-1 5c89629e5873072a9ca3956b67cf7b5080312c80 9a6795333e3352b56a8fd506e463ef634b7636d2
SHA-256 6e6d3a831c03b09d9e4a54859329fbfd428083f8f5bc5f27abbfdd9c47ec0e57 4a0688baf9661d3737ee82f8992a0a665732c91704f28688f643115648c107d4
Размер (в байтах) 50 176 43 520

Ниже мы поделимся результатами исследования 64-битной версии.


Функциональные возможности загрузчика


Файл rasautoex.dll предназначен для загрузки основного тела Taidoor в память системы. Он может быть запущен через вызов экспортируемой функции MyStart или зарегистрирован как служба об этом свидетельствует экспортируемая функция ServiceMain.


Поведение в системе


При запуске загрузчик ищет в той же директории, в которой он находится, файл svchost.dll зашифрованное основное тело Taidoor. Обнаружив необходимый файл, загрузчик выполняет следующие действия:


  1. Загружает содержимое файла в память.
  2. Расшифровывает файл алгоритмом RC4 на ключе ar1z7d6556sAyAXtUQc2. В расшифрованном виде svchost.dll представляет собой 64-битную библиотеку. В случае с 32-битным загрузчиком (ml.dll) библиотека с телом Taidoor, соответственно, 32-битная.
  3. Выполняет маппинг библиотеки в памяти.
  4. Находит и заполняет адреса всех импортируемых функций.
  5. Находит адрес экспортируемой из библиотеки функции Start. Если такая функция найдена, вызывает ее.

Индикатор компрометации (IoC)

Строка: ar1z7d6556sAyAXtUQc2


Основное тело Taidoor


Основное зашифрованное тело Taidoor представлено в виде одного из файлов svchost.dll, которые отличаются разрядностью. Их свойства описаны в табл. 2.


Табл. 2. Свойства файлов основного тела Taidoor


Свойства 64-битная версия 32-битная версия
Имя файла svchost.dll svchost.dll
Тип файла Зашифрованный PE32+ Executable (DLL) Зашифрованный PE32 Executable (DLL)
Класс ВПО Троян удаленного доступа (Remote Access Trojan) Троян удаленного доступа (Remote Access Trojan)
MD5 6627918d989bd7d15ef0724362b67edd 8cf683b7d181591b91e145985f32664c
SHA-1 21e29034538bb4e3bc922149ef4312b90b6b4ea3 f0a20aaf4d2598be043469b69075c00236b7a89a
SHA-256 0d0ccfe7cd476e2e2498b854cef2e6f959df817e52924b3a8bcdae7a8faaa686 363ea096a3f6d06d56dc97ff1618607d462f366139df70c88310bbf77b9f9f90
Размер (в байтах) 183 808 158 208
C2 www[.]infonew[.]dubya[.]net:443 210.68.69.82:443
www[.]cnaweb[.]mrslove[.]com:443

В файле с MD5-хешем, оканчивающимся на 7edd, зашифрована 64-битная версия программы. В файле с MD5-хешем, оканчивающимся на 2664c, 32-битная. Файлы почти идентичны, но в них прописаны разные адреса серверов управления.


Далее речь пойдет об исследовании 64-битной версии.


Общая характеристика исследуемого образца Taidoor


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


При запуске с помощью rundll32 Taidoor проверяет наличие сохраненных вне тела программы зашифрованных настроек в параметре RValue ключа реестра SOFTWARE\Microsoft\Windows NT\CurrentVersion. При их отсутствии или другом типе запуска программа использует стандартные настройки, сохраненные в ее теле.


Далее Taidoor расшифровывает настройки, которые включают в себя следующие данные:


  • адреса сервера управления (домены или IP-адреса и порты);
  • адрес прокси-сервера (необязательно);
  • настройки ожидания (время переподключения к серверу в различных ситуациях);
  • публичный RSA-ключ сервера.

Если указан прокси, программа пытается подключиться к серверу управления через него. При подключении Taidoor отправляет один зашифрованный по алгоритму RSA пакет с идентификатором и ждет от сервера ответ. Если попытка успешна, программа создает файл %ALLUSERSPROFILE%\\Application Data\\Microsoft\\~svc_.TMp вероятнее всего, это индикатор успешного заражения, который предотвращает повторную загрузку Taidoor.


Программа в ходе основного цикла инициализирует два плагина: один для сбора информации о системе, другой для создания процессов и работы с командной строкой.


После этого программа запускает в отдельном потоке цикл отстука, в котором она обращается к управляющему серверу каждые 10 секунд. В основном же потоке программа начинает цикл получения команд от сервера. При отправке сообщений на сервер используется криптоконверт RSA + AES. На каждое сообщение генерируется отдельный ключ AES.


Вот какие действия может совершать злоумышленник в зараженной системе при помощи Taidoor в базовой комплектации (основной модуль и два встроенных плагина):


  • сохранять файлы на диск,
  • изменять настройки подключения к серверу управления,
  • загружать новые модули,
  • подменять временные метки у файлов,
  • запускать процессы и получать их результаты,
  • взаимодействовать с командной строкой.

У каждого плагина Taidoor есть свой идентификатор, который указывается в начале каждого сообщения с обеих сторон. Это позволяет оператору программы адресовать команды конкретному плагину и различать источники сообщений от программы (основной модуль и конкретные плагины). По умолчанию используются следующие идентификаторы:


  • 1 основной модуль;
  • 2 плагин для старта процессов и работы с командной строкой;
  • 3 плагин для получения дополнительной информации о системе.

Внешние плагины Taidoor загружает в виде динамических библиотек по команде с сервера управления. В каждом плагине есть три экспортируемые функции:


  • Install инициализация плагина и возвращение идентификатора плагина;
  • Proxy передача плагину адресованного ему сообщения от сервера;
  • Uninstall деинициализация плагина.

Taidoor применяет всевозможные методы, чтобы затруднить обнаружение и расследование атаки:


  • Вместо оригинального файла может использоваться копия cmd.exe.
  • Временные метки индикатора заражения %ALLUSERSPROFILE%\\Application Data\\Microsoft\\~svc_.TMp заменяются временными метками системного файла C:\Windows\System32\services.exe, что осложняет определение даты заражения.
  • Файлы загружаемых плагинов удаляются после запуска.
  • До старта процессов плагин проверяет, нет ли на атакуемой машине антивируса Kaspersky.

Инициализация Taidoor


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


В начале процесса используется механизм для препятствования ручной отладке, в ходе которого программа:


  1. считает, сколько секунд по времени от 0 до 60 должно быть через 10 секунд;
  2. запускает цикл, ждет по 10 секунд на каждой итерации до тех пор, пока не получит ожидаемое значение.

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


После запуска Taidoor препятствует ручной отладке с помощью примитивной функции.


Далее программа сама импортирует все необходимые функции за исключением LoadLibrary и GetProcAddress.


Taidoor вызывает еще несколько неопасных и бессмысленных функций (рис. 1), скорее всего, чтобы защититься от обнаружения.


"
Рис. 1. Пример бесполезной функции, используемой Taidoor


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


Соединение с сервером управления


В начале основного цикла Taidoor проверяет имя приложения, при помощи которого малварь была запущена, чтобы определить источник параметров соединения с управляющим сервером:


  • Если использовалась стандартная утилита rundll32.exe, то программа пытается загрузить параметры соединения с сервером из параметра RValue ключа реестра SOFTWARE\Microsoft\Windows NT\CurrentVersion.
  • Если библиотека была запущена иным способом или параметр RValue не существует, настройки берутся из тела Taidoor.

Настройки, полученные тем или иным способом, расшифровываются алгоритмом AES в режиме ECB с ключом 2B7E151628AED2A6ABF7158809CF4F3C (представлен в шестнадцатеричном виде).


Далее Taidoor пытается подключиться к серверу управления. В полученных ранее параметрах подключения может быть указано до 4 адресов сервера и до 3 портов на каждый сервер. Также может быть указан адрес и порт HTTP-прокси-сервера. В изученном образце был указан один управляющий сервер и один порт, а в 32-битной версии указаны два управляющих сервера и по одному порту на каждый.


Подключение проходит по следующему алгоритму:


  1. Программа берет адрес и порт из конфигурации. Если в конфигурации указаны параметры прокси-сервера, то программа пытается подключиться к нему.
  2. Программа подключается к серверу управления или дает прокси-серверу соответствующую команду (при наличии параметров прокси и успешном подключении к нему).
  3. Программа отправляет на управляющий сервер массив из 263 символов, где:
    • первые 3 символа фиксированная строка F::;
    • следующие 4 количество миллисекунд, прошедших между стартом системы и запуском программы;
    • оставшиеся 256 строка 0x040x230x190x340xfe0xc1, зашифрованная при помощи алгоритма RSA_PKCS1v1.5 с использованием криптографически стойкого генератора псевдослучайных чисел (ГПСЧ).
  4. В ответ программа ожидает строку 200 OK\r\n\r\n:
    • Если программа получает такой ответ, фаза подключения к серверу завершается.
    • Если программа не получает ожидаемого ответа, то она пробует соединиться со следующим сервером, указанным в параметрах. Если ни к одному из них не удается подключиться, программа засыпает на указанный в параметрах период времени (в данном образце 30 минут), затем повторяет описанный выше цикл.

Работа с временными метками


Перед соединением с сервером управления Taidoor открывает журнал событий системы и начинает по очереди читать записи. Особое внимание при этом программа обращает на записи типов 6005(Начало работы службы журнала событий) и 6006 (Конец работы службы журнала событий) они могут использоваться для определения времени работы машины. В рассмотренном экземпляре реализован проход по этим данным, но программа их не использует.


После подключения к серверу программа создает файл %ALLUSERSPROFILE%\\Application Data\\Microsoft\\~svc_.TMp, а также обновляет его временные метки. Затем программа проверяет файл C:\Windows\win.ini на наличие секции Micros с ключом source. Если ключ присутствует, утилита cmd.exe копируется по указанному в ключе адресу (в отчете CISA указан адрес c:\temp\cmd.exe).


Функциональные возможности основного модуля


Если в первом байте расшифрованного буфера, пришедшего от сервера, стоит 1, остаток буфера обрабатывается самой Taidoor. Отдельные команды могут устанавливать или использовать глобальные переменные. Вот самые важные из них:


  • <имя_файла>;
  • <файловый_дескриптор>;
  • <идентификатор>;
  • <глобальный_массив>;
  • <дополнительное_имя_файла>;
  • <дополнительный_дескриптор_файла>.

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


С полным списком команд можно ознакомиться тут. Обратите внимание, что команды есть не у всех идентификаторов.
Идентификатор Команда
2 Отключиться от сервера
3 Создать в текущей директории файл с именем }{. Деинициализировать все плагины. Завершить процесс
4 Загрузить плагин из директории по пути, переданному сервера управления. При успешной инициализации удалить все файлы с именем uaq*.dll в текущей директории.

Если инструкции выполнены, отправить серверу сообщение \x01\x05 и тип плагина.

Если во время работы произошла ошибка, отправить на сервер сообщение \x01\x06, конкатенированное с описанием ошибки:
Can't find plug file не получилось найти файл,
Can't load more plug уже загружено максимальное количество плагинов,
Load Dll Plug Failed возникли проблемы при загрузке
7 Деинициализировать плагин указанного типа. Если получилось, отправить на сервер сообщение \x01\x08, если нет сообщение \x01\x06Can't find plug file
9 Отправить на сервер сообщение \x03\x06 и массив из конфигурации. Попытаться открыть файл %temp\~lpz.zp..

Если получилось, отправить файл в нескольких сообщениях частями по 6000 символов. В сообщении каждая тысяча символов оригинального файла разделена переносом строки, а каждому отсылаемому сообщению предшествует код \x03\x07. После отправки содержимого файл удаляется
10 Сохранить полученный массив (новую конфигурацию) в параметр RValue ключа SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion.

Если получилось, отправить конфигурацию на сервер с кодом \x03\x06
11 Попытаться открыть файл с указанным в сообщении именем.

Если не получилось, отправить серверу сообщение \x03\x05Can't open update file и закончить обработку команды.

Если получилось, проверить его размер. Если файл пуст, отправить серверу сообщение \x03\x05File too small и закончить обработку.

Если обработка продолжается, создать <глобальный_массив> и сохранить туда содержимое файла.

Если <дополнительный_дескриптор_файла> открыт, закрыть его, файл <дополнительное_имя_файла> переместить в текущую директорию с именем <5 случайных символов латинского алфавита в нижнем регистре>. XMP-файл из сообщения переместить на место <дополнительное_имя_файла>. После этого файл, указанный в сообщении, открывается как <дополнительное_имя_файла>.

Вне зависимости от того, был ли открыт до этого <дополнительный_дескриптор_файла>, удалить файл с именем из сообщения (если он не был перемещен), удалить параметр RValue из ключа реестра SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion.

В конце отправить на сервер сообщение \x03\x04aaa
12 Проверить, инициализирован ли плагин с указанным типом. Если да, отправить серверу сообщение \x01\x0d, если нет \x01\x0e
15 Скопировать остаток буфера в переменную <имя_файла>. Попытаться открыть файл на запись и сохранить соответствующий дескриптор в <файловый_дескриптор>.

Если не получилось открыть файл или переданный путь к файлу длиннее 260 байт, отправить на сервер сообщение с ошибкой \x01\x06Create File Failed\x00.

Если все прошло успешно, отправить \x01\x10
17 Записать остаток буфера в ранее открытый <файловый_поток>
18 Если <файловый_дескриптор> открыт, закрыть его. Заменить значения временных меток файла <имя_файла> на значения временных меток файла C:\Windows\System32\services.exe. Отправить на сервер сообщение \x01\x13 вместе с <имя_файла>
20 Закрыть <файловый_дескриптор>, удалить файл <имя_файла>
32 Отправить \x01\x21 и <идентификатор> на сервер
34 Отключиться от сервера

На рис. 2 можно увидеть реализацию команды с идентификатором 15, которая запускает процесс открытия файла.



Рис. 2. Часть обработчика открытия файла


Работа плагинов


Инициализация плагинов


Taidoor инициализирует два встроенных плагина:


  • MyPlugCmd для исполнения команд на машине. В качестве одного из аргументов при инициализации передается путь, по которому располагается копия cmd.exe. Если необходимый ключ в win.ini не найден или копирование сорвалось, передается пустая строка.
  • MyPlugInfo для получения базовой информации о зараженной машине.

Вот как выглядит процесс загрузки нового плагина (функция представлена на рис. 3):


  1. Библиотека загружается в память.
  2. Программа проверяет плагин на наличие следующих экспортируемых функций:
    • Install,
    • Uninstall,
    • Proxy.
  3. Программа вызывает функцию Install, передает в нее информацию о подключении к серверу управления. В качестве идентификатора выставляется полученное из Install значение.
  4. После инициализации модуль добавляется в массив плагинов и, если имя файла соответствует схеме uaq*.dll, файл удаляется.


Рис. 3. Функция загрузки плагина


Каждый модуль может быть деинициализирован, чтобы предоставить место другому.


При получении команды от сервера управления Taidoor проверяет первый байт, который указывает на адресата: команда может быть предназначена либо для основного модуля, либо для одного из плагинов. Если команда должна быть передана плагину, остаток сообщения передается в функцию плагина Proxy.


Активировав плагины, Taidoor в отдельном потоке запускает функцию периодического обращения к серверу. В этой функции программа каждые 10 секунд отправляет управляющему серверу сообщение \x01\xff.


Все обращения к серверу здесь и далее создаются по следующему алгоритму:


  1. Высчитывается размер данных с паддингом. Он будет равен длине сообщения + 4 байта это значение округляется до 16, обязательно в большую сторону. Например, 16 20 32, a 12 16 32.
  2. Изначальный размер записывается в первые 4 байта нового массива с вычисленным размером. Сразу после него копируются передаваемые данные (т. е. по отступу 4). Лишние байты в конце массива заполняются нулями. Таким образом данные запаковываются для симметричного шифрования.
  3. Программа генерирует временный ключ из 16 символов нижнего регистра в латинском алфавите. Механизм генерации небезопасен, поскольку позволяет перебрать все возможные варианты за приемлемое время. К тому же если известно примерное время заражения, можно сократить количество вариантов.
  4. Программа шифрует созданный ключ при помощи алгоритма RSA_PKCS1v1.5 с использованием криптографически стойкого ГПСЧ на ключе, взятом из параметров.
  5. Программа шифрует запакованный массив при помощи алгоритма AES-128 в режиме ECB на временном ключе.
  6. Программа отправляет на сервер 4 байта полного размера пакета: 256 (размер зашифрованного ключа) + размер зашифрованных данных. Если удалось отправить размер, то программа последовательно посылает 256 байт зашифрованного ключа и зашифрованные данные.

Общение плагинов с сервером управления


Включив плагины, малварь начинает получать команды от сервера управления. Дальнейшие действия вредоноса зависят от команд.


Если при получении данных от сервера возникла ошибка, программа завершает соединение и ждет столько времени, сколько установлено в параметрах (в изученном образце это 1 секунда), после чего вновь пытается подключиться к серверу.


Если сервер ответил пустым сообщением, программа это запоминает. Если сервер ответил так 300 раз подряд, программа завершает соединение и столько времени, сколько установлено в параметрах (в изученном образце это 30 минут), после чего пытается подключиться снова.


Если размер сообщения от сервера больше или равен 256 байтам, то программа действуют по следующему алгоритму:


  1. Taidoor берет первые 256 байт и расшифровывает их на публичном ключе RSA c применением RSA_PKCS1v1.5. Полученные данные используются в качестве симметричного ключа для следующих данных. Использование подписи в данном случае бессмысленно, так как не защищает от перехвата управления.
  2. Программа использует полученный ключ, чтобы расшифровать остаток сообщения алгоритмом AES-128 в режиме ECB.
  3. В первый байт полученного массива записывается идентификатор адресата команды:
    • Если он равен 1, то остальные данные предназначаются для основного модуля и обрабатываются в отдельной функции.
    • Все остальные значения обозначают тот или иной плагин. Программа ищет его и передает ему данные. Если такой плагин не найден, программа не делает ничего.

Функциональные возможности плагинов


Встроенный модуль MyPlugCmd предназначен для запуска процессов и передачи команд консоли. При инициализации ему передается параметр, который может быть сохранен в файле C:\Windows\win.ini. Этот параметр указывает на копию cmd.exe, которая используется, чтобы затруднить обнаружение программы.


Модуль хранит несколько переменных в своем теле. Вот наиболее важные из них:


  • <файловый_дескриптор>;
  • <имя_файла>;
  • <альтернативный_путь_к_cmd>;
  • <шелл>.

Стоит отметить, что переменная <шелл> хранит информацию о запущенном процессе консоли, которая нужна для записи в поток ввода данного процесса и получения данных из потока вывода.


Полный список команд, выполняемых модулем MyPlugCmd можно посмотреть тут.
Идентификатор Команда
1 Проверить, что среди запущенных процессов нет avp.exe (антивируса Kaspersky):
Если он найден, отправить \x02\x07kb и закончить обработку.
Если не найден, проверить, инициализирована ли переменная <альтернативный_путь_к_cmd>. Если нет, то записать туда cmd.exe.

Затем создать процесс <альтернативный_путь_к_cmd> с перенаправленным вводом-выводом.

При успешном запуске поместить информацию о процессе вместе с дескрипторами перенаправления ввода-вывода в <шелл>, а в файл C:\Windows\win.iniдобавить секцию Micros c ключом source со значением <альтернативный_путь_к_cmd>. Также запускается дополнительный поток, в котором каждые 32 миллисекунды до 4096 байт вывода запущенного процесса отправляются на сервер с идентификатором \x02\x09.

При ошибке создания процесса отправить на сервер сообщение \x02\x03, при успехе \x02\x02
4 Если <шелл> инициализирован, завершить его процесс и отправить на сервер \x02\x05.

Если нет отправить на сервер \x02\x06no shell
8 Записать остаток буфера в поток ввода <шелл>
10 Сохранить путь к файлу, переданный в сообщении, в <имя_файла>, открыть его для чтения и сохранить дескриптор в <файловый_дескриптор>.

При ошибке отправить \x02\x0eCreate File Failed, при успехе \x02\x0b
12 Сохранить остаток буфера в переменную <имя_файла>, открыть этот файл для чтения, сохранить дескриптор в <файловый_дескриптор>.

Если возникла ошибка при открытии файла, отправить на сервер \x02\x0eOpen File Failed.

Еcли он пуст \x02\x03File Size is 0. При обеих ошибках закончить обработку команды.

Если файл открыт и он не пустой, отправить на сервер сообщение \x02\x0d. Также запустить дополнительный поток, в котором содержимое файла будет отправляться на сервер в сообщениях с идентификатором \x02\x0f частями по 4096 байт с промежутком в одну миллисекунду. Остаток файла не отправлять.

Завершить процесс сообщением \x02\x12 и закрытием <файловый_дескриптор>
15 Подать остаток буфера на вход процессу <шелл>, если он инициализирован
16 Обновить временные метки у файла <имя_файла>, скопировав временные метки файла C:\Windows\System32\services.exe. Отправить серверу сообщение \x02\x11
19 Закрыть <файловый_дескриптор>, удалить файл <имя_файла>
31 Cоздать временный файл и запустить файл, расположенный по пути из остатка буфера, перенаправляя вывод во временный файл.

Если произошла ошибка при создании временного файла, отправить сообщение об ошибке \x02\x20Create result file failed.

Еcли при запуске файла по пути из остатка буфера произошла ошибка, отправить сообщение \x02\x32CreateProcess Error:, конкатенированное с кодом ошибки.

Если запуск прошел успешно, читать из временного файла по 4096 символов и отправлять их с кодом сообщения \x02\x21 каждую миллисекунду
34 Запустить файл, расположенный по пути из остатка буфера. При удачном запуске отправить серверу сообщение \x02\x32CreateProcess succ, при ошибке сообщение \x02\x32CreateProcess Error:, конкатенированное с кодом ошибки.
37 Заменить <альтернативный_путь_к_cmd> остатком полученного буфера. Отправить серверу сообщение \x02\x26

Встроенный модуль MyPlugInfo может собирать и отправлять на сервер информацию об IP-адресах и MAC-адресах сетевых интерфейсов, идентификатор текущего процесса, а также идентификаторы заражения. Еще он умеет выполнять команду 11 основного обработчика.


Команды с идентификаторами можно найти тут
Значение байта Команда
1 Собрать информацию об IP-адресах и MAC-адресах сетевых интерфейсов, идентификатор текущего процесса, а также идентификаторы заражения (устанавливаются при инициализации плагина). Отправить всю эту информацию на сервер с кодом \x03\x02
3 Выполнить команду 11 основного обработчика

Индикаторы компрометации (IoC) обоих вариантов svchost.dll
Файл Параметр реестра
%ALLUSERSPROFILE%\\Application Data\\Microsoft\\~svc_.TMp RValue в ключе SOFTWARE\Microsoft\Windows NT\CurrentVersion
Подробнее..

Поиск коллизий в SHA-256 на платформе Node.js при помощи Bitcoin Hasher

09.06.2021 14:20:05 | Автор: admin

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

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

Для понимания работы приложения Bitcoin Hasher содержание статьи было поделено на небольшие разделы:

  1. Немного теории

  2. Немного о SHA-2

  3. Немного о Blockchain

  4. Bitcoin Hasher

  5. Полезные материалы

1. Немного теории

Алгоритмом шифрования называется некая функция принимающая на вход строку произвольной длины, которая посредством определённого математического алгоритма преобразует INPUT (строку произвольной длины) в OUTPUT (строку фиксированной длины). Данный процесс конвертации называется хешированием или шифрованием. Конечным результатом шифрования любой подающей на вход информации называется цифровым отпечатком (дайджестом). Цель любого алгоритма заключается в сжатии, рассеивании и перемешивании входной информации. Оттого насколько сильно она преобразована будет зависеть не только безопасность этого самого отпечатка, но и алгоритма хеширования посредством которого был сформирован отпечаток. Наглядный процесс конвертации показан на схеме:

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

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

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

  3. Отсутствие какой-либо зависимости между входной и выходной информацией

  4. Сложность или невозможность подбора входного значения для цифрового отпечатка

Целью шифрования информации при выборе наиболее стойкого и нового стандарта является сохранение и необратимое преобразование исходных данных, что на мой взгляд является и одним из важнейших его преимуществ. Недостатком - появление неизбежных коллизий при преобразовании. Предположим что есть два отличающихся информацией входных блока (x) которые нужно "пропустить" через функции хеширования (H) и получить фиксированной длины отпечатки (y). Если блоки (x) проходящие через функции (H) будут иметь одинаковые отпечатки (y) значить в результате выполненной работы образуется коллизия:

2. Немного о SHA-2

На момент написания этой статьи одним из наиболее эффективных алгоритмов хеширования является семейство криптографических систем защиты информации SHA-2 (Secure Hash Algorithm Version 2 - безопасный алгоритм хеширования, версия 2).

Все функции, которые входят в данное "семейство", а именно: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/256 и SHA-512/224 построены на основе структуры Меркла-Дамгарда, что сказывается на их реальной стойкости к различным видам атак. Принцип работы абсолютно всех вышеприведённых алгоритмов заключается в разбивке входящей информации на части одинакового размера, каждая из которых подвергается обработке выбранной односторонней функцией сжатия. Ключевым преимуществом при таком подходе является алгоритмическая односторонность, то бишь невозможность восстановления каких-либо исходных данных на основе полученного выходного результата без наличия сформированного ключа. Данное элегантное решение было представлено взамен устаревшему SHA-1 Агентством Национальной Безопасности США в 2002 году для более надёжного шифрования конфиденциальных данных. Одним из наиболее применимых на сегодняшний день алгоритмов является SHA-256, свою популярность по внедрению его в различные системы он завоевал благодаря таким масштабным проектам как: Bitcoin и Blockchain (о Blockchain далее остановимся чуть подробнее). Все представленные функции благополучно работают и применяются по сегодняшний день.

Ниже представлен результат работы каждого из алгоритмов, которые входят в семейство SHA-2:

SHA-224:       Hello World ! --> 2c8abaa6a94a76fe9c6005994567d67a1631bc90dfca267099dc750fSHA-256:       Hello World ! --> 07f2bdef34ed16e3a1ba0dbb7e47b8fd981ce0ccb3e1bfe564d82c423cba7e47SHA-384:       Hello World ! --> 67e60f9ce837caa3ca82550f0dfcbde1b8b8a7c1605fa8d115bcc2314204fd95f5f607306622c38c0205de7df6d426d8SHA-512:       Hello World ! --> feab0028f1142d420a1425d1dd5b518225b4523aa1cff63385ece3411318819f5ec83042ccb79d81f20e4a243866886ca3ae3026153acff8e126c0e89631502eSHA-512/256:   Hello World ! --> a70e1d1268e729e90db4c0834214f449c8e7b652777f40a8a0d26f2372e39ca7SHA-512/224:   Hello World ! --> 7cc0d174b7ce522eff7d7ee59789e420d75d0244f006ef8ce0f4efb7

3. Немного о Blockchain

Для понимания работы приложения я обязан написать пару слов о Blockchain сети так как именно она базируется на работе с алгоритмом SHA-256 а, также является важным "поставщиком входной информации" для Bitcoin Hasher.

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

Окунувшись в историю формирования технологии, работы и исследования учёных для удобства были разбиты на несколько этапов:

  1. (1991 год): Размышления о Blockchain, как о защищённом хранилище цифровых документов без возможности их подделки или возврата были описаны в работах Стюарта Хаббера и У. Скотта Шторнетта в 1991 году. Столь гениальная и стойкая идея была сформулирована задолго до появления Blockchain-сети.

  2. (1992 год): Для надёжной работы Blockchain в дизайн работы будущей сети инкорпорировали так называемое дерево Меркла, что впоследствии привело к налаживанию связей между всеми записями данных во всей цепочке глобальной экосистемы Blockchain.

  3. (2008 год): Некий человек или организация под псевдонимом Сатоши Накамото публикует документ под названием: "Bitcoin: a peer-to-peer electronic cash system". Данный документ впоследствии станет отправной точкой создания нынешнего Blockchain для валюты Bitcoin.

  4. (2009 год): В альтернативу нынешней финансовой системе Сатоши Накамото реализовывает децентрализованную, не подконтрольную не одной государственной единице, сеть Blockchain для работы с первой в мире цифровую валюту Bitcoin.

Программное решение продукта было спроектировано таким образом, что любое вмешательство в её работу не приведёт абсолютно ни к чему, так как парадигмы, которые были заложены в Blockchain с самого её основания остаются стойкими, актуальными и применимыми по сегодняшний день.

Вся информация о переводах в Blockchain хранится в виде блоков, каждый из которых представляет собой объект и имеет следующий вид (Пример блока под номером 685466, созданный 2021-05-30 08:05):

{      "hash": "00000000000000000009fde417c010d7ec9ffb25a268f4b0667681ed9b74cf65",       (уникальный идентификатор созданного блока)      "ver": 536870916,                                                                 (версия блока)      "prev_block": "00000000000000000007b7241ee4748769266870bdab4e5306379739db07c466"  (уникальный идентификатор предыдущего блока),      "mrkl_root": "8d620000ab7ba942a165ed49be563a31c33269ce8f2d40b8317784475a543fe7"   (хеш всех транзакций в текущем блоке),      "time": 1622351111                                                                (время за которое был создан текущий блок),      "bits": 386752379                                                                 (суб-единица BTC),      "nonce": 3069945434                                                               (случайное значение которое можно скоректировать для подтверждения работы),      "n_tx": 996                                                                       (колличество подтвержденных транзакций в текущем блоке),      "size": 1602081,                                                                  (размер текущего блока)      "block_index": 685466                                                             (индекс текущего блока),      "height": 685466                                                                  (высота текущего блока),      "tx": [         "--Array of Transactions--"                                                    (Массив транзакций содержащих информацию)      ]   }

Достоверную информацию о всех блоках и транзакциях, можно получить на сайте Blockchain, в разделе API.

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

4. Bitcoin Hasher

Bitcoin Hasher представляет собой небольшое приложение для поиска коллизий в алгоритме шифрования SHA-256.

Осуществление поиска производится путем создания так называемого "двойного шифрования" цифровых отпечатков. То бишь из уже ранее зашифрованной информации полученной из Blockchain, приложение генерировало подобный отпечаток для каждой из транзакций посредством применения SHA-256.

Алгоритм работы сводился к следующему:

  1. На клиенте JavaScript делал новый XHR-запрос к Blockchain API следующего вида: https://blockchain.info/rawblock/ (уникальный идентификатор блока вводимый в input приложения).

  2. После отправки запроса к Blockchain серверам, в ответе Bitcoin Hasher получал детальную информацию о блоке, пример которой я уже описывал.

  3. Из поля "tx" приложение "забирало" массив дайджестов подтвержденных транзакций в конкретном блоке и на их основе Node.js генерировал точно такой же цифровой отпечаток каждой из транзакций.

  4. Параллельно работы генерации из поля "prev_block" (в которое входит значение идентификатора предыдущего блока) на клиенте JavaScript создавал новый XHR-запрос следующего вида: https://blockchain.info/rawblock/ (уникальный идентификатор предыдущего блока). Данный процесс был зациклен до тех пор пока все блоки и транзакции не будут обработаны.

  5. При параллельной работе клиент-серверного приложения все INPUT-OUTPUT данные записываются в папку db_blocks/block-NUMBER_BLOCK.txt

  6. Итоговой задачей остается найти INPUT дайджест, который является ключом к интересующему вас OUTPUT отпечатку.

Полезные материалы для ознакомления с приложением:

Repository Bitcoin Hasher

Пример формирования "двойного шифрования", для блока с высотой 665862 в Blockchain

Процесс работы Bitcoin Hasher:

5. Полезные материалы

  1. Алферов А. П., Зубов А.Ю., Кузьмин А.С., Черемушкин А. В. Основы криптографии. М.: Гелиос АРВ, 2001. 479 с.

  2. Децентрализованные приложения. Технология Blockchain в действии. С. Равала

  3. Практическая криптография. Нильс Фергюсон и Брюс Шнайер

Подробнее..

Исследование операций

16.06.2021 16:13:28 | Автор: admin
Cодержание
  1. Введение

  2. Основные понятия и термины

  3. Характеристика ИО как научной дисциплины

  4. Этапы операционного исследования

    • Постановка задачи

    • Построение математической модели

    • Нахождение решения с помощью математической модели

    • Проверка модели и решения

    • Построение процедуры подстройки и решения

    • Осуществление решения

  5. Предметные процессы ИО и задачи

    • Процессы обслуживания

    • Распределения

    • Управления запасами

    • Замены

    • Состязательные

  6. Модели процессов ИО и их логическая структура

    • Постановка задачи

    • Элементы задачи ИО

    • Взаимодействие исполнения и управления при ИО

  7. Литература

Введение

При функционировании больших сложно устроенных систем в них, как правило, протекают многообразные процессы, сущность которых состоит в различного рода преобразованиях физико-химической субстанции из сырья в конечный продукт, поставляемый на рынок. Наряду с материальной субстанцией в производственных процессах широко используется информация управленческая и технологическая. Когда-то не в столь давние времена достаточно сложным механизмом, системой считался часовой механизм, реализуемый зацеплением шестеренок. Механизм преобразовывал временную субстанцию в информацию. Выходным продуктом такого механизма была информация - сведения о текущем временном моменте, к точности которой уже в те времена предъявлялись жесткие требования. Все процессы сложных производственных систем также, подобно механизму часов, постоянно должны быть в "зацеплении", тесно взаимодействовать, протекать синхронно и согласованно. Главным требованием к такой системе с шестеренками была точность отсчетов временных промежутков. И сегодня точность нужна везде от водных, наземных, воздушных транспортных систем до спутниковых космических, атомных энергетических станций. Исследуя операции, следует помнить об истории их появления и проявления в различных отраслях хозяйства и производства.

Начнем с рассмотрения типичной простой и понятной задачи. Пусть в пределах населенного пункта в точках 0, х1) имеется n складов с товарами. На каждом складе припаркован под погрузку автоприцеп, который загружается товарами. В других точках 0, х1) района (окрестности населенного пункта) размещаются заказчики (потребители товаров), которым необходимо эти товары доставить. В n точках 0, х1) размещены n тягачей, которые должны доставить заказчикам загруженные товарами по их заявкам автоприцепы. Такая доставка связана с расходом топлива, с затратами времени и многими другими явлениями и событиями.

Владелец транспортных средств располагает матрицей:

С = [c_{ij}], i = 1(1)n, j = 1(1)n,

стоимости (затрат) топлива в операции перевозки.

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

Q(X[i,j]) = \sum_{i=1}^{n}\sum_{j=1}^{n}{c_{ij}x_{ij}} min.

Это соотношение называют целевой функцией (ЦФ). Неизвестными здесь являются переменные (xij) , т.е. куда тягач с номером (i) должен доставить груженый прицеп с номером (j). Ясно, что суммарные затраты будут определяться планом Х[i, j] перевозок или выбором переменных (xij) в совокупности. Постоянно будем иметь ввиду очевидное ограничивающее условие: один тягач везет один прицеп, каждый прицеп обслуживается одним тягачом. Из этого условия следует, что каждый элемент (xij), выбираемый для подстановки в ЦФ, не может быть дробным значением, а принимает одно из значений 0 или 1, т.е. (xij 0, i = 1(1)n, j = 1(1)n).Приведенное выше условие интерпретируется в модели как ограничения, накладываемые напеременные (xij).

(i = 1) х1112 ++ х1j + + x1n = 1, j = 1(1)n;

(i = 2) х2122 ++ х2j + + x2n = 1, j = 1(1)n;

(i = 3) х3132 ++ х3j + + x3n = 1, j = 1(1)n;

.. .

(i = i) хi1 + хi2 + + хij + + x in = 1, j = 1(1)n;

. .. .. . . .. .

(i = n) хn1n2 ++ хnj + + x nn = 1; j = 1(1)n.

Каждая (i-я) строка обозначает возможность прибытия на (j-й) склад любого (j-го) из (n) тягачей и представляется суммой, в которой будет выбран один единственный элемент (xij = 1). Относительно столбцов j = 1(1)n системы уравнений также составляются суммы, и каждая из таких сумм также равна единице. В столбцовых суммах также выбирается единственный элемент(xij = 1) Таким образом, будет выбрана таблица (0,1-матрица), заполненная единицами и нулями, но так, что в каждой строке и в каждом столбце оказывается единственная единица. Такие матрицы в математической статистике называются дважды стохастическими. Каждая матрица реализует план Х перевозок и ему соответствует определенное (после подстановки переменных плана в выражение целевой функции) значение ЦФ. Сколько же планов-решений Х можно построить? Это легко посчитать. Первый тягач можно направить в любой из n складов, но второму тягачу будут доступны только n1 складов, третьему n2 складов. Этим трем тягачам соответствует n(n1)(n2) количество планов равное произведению трех сомножителей. Далее число возможностей выбора склада будет сокращаться (для 4-го тягача только n3 выборов), а для последнего nго тягача останется единственная возможность, так как все остальные склады уже распределены между n1 тягачами, всего планов будет |Х[i, j]|= n! Например, если n = 20, то

|Х[i, j]| = 20! = 2 432 902 008 176 640000.

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

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

Основные понятия и термины ИО

Операция это организуемое мероприятие (система действий), объединенное единым замыслом, обеспеченное средствами, ресурсами, усилиями и направленное к достижению определенной сформулированной цели.

Цель это описание желаемого состояния или запланированного результата деятельности, на создание (получение) которого направлены ресурсы, усилия. Чаще всего цель или цели (дерево целей) оформляются в форме требуемых значений различных показателей (в ТТЗ на НИР, ОКР и др.)

Модель условный образ реального объекта (операции), отражающий его существенные свойства физический или абстрактный: скульптура, барельеф, игрушки, фотография, карта, схема, рисунок, формула, уравнение, система уравнений, неравенств, граф, сеть, совокупность формул, схем и текста.

Решение это какой-то конкретный выбор из полного ряда возможностей (ограничения задачи не учитываются).

Допустимые решения - те решения, которые удовлетворяют наложенным в задаче ограничениям.

Оптимальными решениями являются те допустимые решения, которые по тем или иным соображениям предпочтительнее других и доставляют экстремальные значения ПЭ. Поэтому основной задачей исследования операций является предварительное количественное обоснование оптимальных решений. Предъявление требования к вероятности выполнения задачи одно из главных при организации исследования. Необходимость принятия решения диктуется наличием цели, которую нужно достичь, например, выполнить плановое задание, выбрать тип прибора, построить план перевозок. Если же цель поставлена или фактическое состояние не соответствует желаемому, то имеет место проблемная ситуация, процесс выработки плана устранения которой и составляет сущность задачи принятия решений.Результат операции зависит от способа ее проведения, организации, т.е. от выбора определенных параметров.

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

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

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

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

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

Критерий эффективности (КЭ) правило, обеспечивающее фиксирование итогового успешного результата исследования. Рассматриваются три типа КЭ: критерий пригодности системы (система удовлетворяет требованиям, предъявляемым к ней); критерий сравнения систем (из двух или более выбирается та, ПЭ которой предпочтительнее); критерий оптимальности (из всех возможных значений ПЭ выбирается экстремальное при условии допустимости решения). Сам ПЭ не является критерием, так как критерий - это правило, обеспечивающее окончательное принятие решения о пригодности, превосходстве или оптимальности процесса (системы). КЭ не вычисляется, а проверяется.

Характеристика научной дисциплины ИО

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

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

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

Предметные процессы ИО и задачи

В зависимости от типов системных процессов методы и средства их реализации можно разнести по нескольким классам. Приводимые ниже примеры процессов и задач дают представление о предметной области теории ИО, но конечно, не исчерпывают их множества и разнообразия.

Процессы обслуживания

Такие процессы порождаются возникновением клиента, требующего обслуживания. Процесс обслуживания при этом характеризуется явлением ожидания. Ждет либо клиент, либо система (редкий случай, когда ожидания отсутствуют). Известно, что все виды ожидания связаны с расходами. Задача заключается в том, чтобы регулировать появление клиентов или определять объем и организацию обслуживания с тем, чтобы свести к минимуму оба вида ожидания и связанные с ними расходы.

Для решения описанной задачи с ожиданиями применима теория очередей. Для задачи определения порядка обслуживания клиентов применима теория расписаний. Наконец, к задачам определения распределения и группировки каналов и других элементов процессов обслуживания в систему обслуживания применима теория балансирования линий.

Процессы распределения

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

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

Процессы управления запасами

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

Процессы замены

Существуют два основных класса, связанных с видами износа оборудования: во-первых, оно устаревает и становится несовременным (менее эффективным) в результате длительного срока службы, или появления нового оборудования (например, станки), во-вторых, не устаревает, но полностью выходит из строя, гибнет (например, электролампы). Замена шифрключей, алгоритма шифрования требует определения временного интервала несменяемости шифрключа.

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

Состязательные процессы

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

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

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

Этапы операционного исследования

Как можно представить процесс, порядок операционного исследования? Принято в такое исследование включать следующие пункты.

  1. Постановка задачи.

  2. Построение математической модели изучаемой системы

  3. Нахождение решения с помощью модели.

  4. Проверка модели и получение с ее помощью решения.

  5. Построение процедуры подстройки решения.

  6. Осуществление решения.

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

Построение математической модели (рис.1). Модель выражает эффективность исследуемой системы как функцию множества переменных, из которых по крайней мере одно поддается управлению. Операционная модель в общем виде может быть представлена соотношением

Е = Аrgextr F(x,y, ui),

где Е показатель эффективности системы; х,у неуправляемые переменные, ui управляемые переменные, F(x,y, ui) - целевая функция модели. Ограничения, накладываемые на переменные модели, выражаются системами равенств или неравенств дополнительно к основному соотношению показателю эффективности модели, Аrgextr F(x,y, ui) критерий эффективности примененный к целевой функции. Следует заметить, что в публикациях авторы критерием эффективности называют показатель эффективности, а критерий вообще опускается из рассмотрения. КЭ, трактуемый как правило (руководство), не измеряется числом. К этим вопросам следует отнести и вопрос о существовании разных шкал для проведения измерений с учетом отношения, отвечающего той или иной шкале.

Таблица шкал измерений переменных и отношения (МО - метризованное отношение)Таблица шкал измерений переменных и отношения (МО - метризованное отношение)

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

Рисунок 1 Схема постановки задачи и получения логико-структурных решенийРисунок 1 Схема постановки задачи и получения логико-структурных решений

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

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

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

Методы реализации процессов ИО и их логическая структура

Рене Декарт, описывая развитый им метод научного исследования, формулирует четыре основных его правила [3].

  1. Разбиение сложной проблемы на более простые последовательно до тех пор, пока не будут найдены далее неразложимые компоненты.

  2. Нерешенные проблемы следует сводить к решенным. Этим путем находятся решения простых проблем.

  3. От решения простых проблем следует переходить к решению более сложных, пока не будет получено решение проблемы, которая являлась исходной при разбиении и является конечной в данном процессе.

  4. После получения решения исходной проблемы необходимо рассмотреть все промежуточные, чтобы удостовериться, не пропущены ли какие-нибудь звенья. В случае, когда полнота решения установлена, то исследование завершается; при обнаружении пробела в решении необходимо дополнительное исследование в соответствии с перечисленными правилами. Метод рекомендуется применять всегда при разработке операций

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

Так проверка и корректировка гипотез производятся с помощью хорошо известных пяти методов индукции, создание и развитие которых связано с именами Ф. Бэкона и Дж. Милля [4, 5].

Рисунок 2 Логическая структура проверки гипотез и процесса логико-структурных решенийРисунок 2 Логическая структура проверки гипотез и процесса логико-структурных решений

Причинная связь явлений устанавливается методами единственного сходства (на основе фактов, полученных в наблюдении), единственного различия ( на основе фактов, полученных в эксперименте), объединенным методом (на основе совместно используемых фактов обоих видов). Метод остатков применяется при выявлении неизвестной причины изучаемого явления, а с помощью метода сопутствующих изменений анализируется динамика причинных зависимостей [6, 7 , 9].

Постановка задачи

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

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

Дело в том, что ИО предполагает исследование экономики операций, не исключая при этом своих собственных операций. Неправильные представления об экономической стороне дела создают представления о различиях между реальным процессом и идеализированным. Эти различия не являются чисто белым и\или черным, а определяются чаще всего экономическими соображениями.

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

Элементы задачи ИО

Рассмотрим в деталях элементы задачи. Очевидно, что перед руководителем или группой лиц должна стоять задача. Эти люди не удовлетворены положением дел в какой-то предметной области и стремятся найти решение, чтобы изменить ситуацию в лучшую сторону. Назовем такую группу или отдельного руководителя лицом, принимающим решение (ЛПР). Таким образом, первым элементом задачи является лицо, принимающее решение (часто это заказчик).

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

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

В-четвертых, необходима (должна существовать) возможность выбора между различными (по крайней мере двумя) способами действия или политиками. При отсутствии выбора задача не возникает. Задача всегда включает вопрос: что делать? Но сам этот вопрос становится задачей только в том случае, если существуют различные пути достижения цели. Различные способы действия (стратегии) являются четвертым элементом задачи.

Чтобы сформулировать исследовательскую задачу, необходимо выполнить следующие операции.

  1. Уточнить перечень целей, определенных на первом этапе постановки задачи.

  2. Уточнить перечень различных стратегий достижения целей.

  3. Определить меру (показатель и критерий) эффективности исследуемой системы.

Взаимодействие исполнения и управления при ИО

Планирующая система связывает объект управления с управляющими органами. В процессе деятельности объекта (рис. 3) происходит преобразование одного состояния объекта в другое (10), что зависит от изменения внешних обстоятельств (9) и предписаний (8), вырабатываемых органами управления на основании плановых представлений объекта (5) и оценок текущего состояния объекта управления (7). Оценки вырабатываются на основании показателей и критериев эффективности (5) и информации (6) от объекта управления. Вся эта цепочка определяет один такт в преобразовании объекта из одного состояния в другое. Для каждого такта необходима своя часть плана. Поэтому после выполнения одного такта в самом плане управление передается следующей его части, что обозначается стрелкой (2) на рис. 3.

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

Такая настройка состоит в выборе дескриптивных и прескриптивных частей плана, которые отвечают требованиям текущего момента. Именно здесь могут выбираться способы перехода, варианты, категории и т. д. В этой настройке определенную роль играет получение информации от окружающей среды (3).

Рисунок 3 План и его связи с частями объектаРисунок 3 План и его связи с частями объекта

Итак, логическая структура планов, их синтаксические и семантические характеристики непосредственно связаны с обобщенным анализом поведения соответствующих объектов. Оно представляется как чередование двух операций тактов преобразований состояний объектов управления и настройки планов на их объекте. На практике это позволяет проводить логический анализ процессов реализации планов как процессов применения знаний.

Литература

1.Азгальдов Г. С., Райхман Э. П. О квалиметрии. М.: Изд. Стандартов, 1973.172 с.

2.Ваулин А. Е. Методы цифровой обработки данных. СПб.: ВИККИ им. А. Ф. Можайского, 1993. 106 с.

3. Декарт Р. Рассуждения о методе с приложениями (Диоптрика, Метеоры, Геометрия) М.: Изд-во АН СССР, 1953.с.9-66.

4.Бэкон Ф. Новый органон. М.: Соцэкгиз,1938. 244 с.

5.Гэри М., Джонсон Д. Вычислительные машины и трудно решаемые задачи. М.: Мир, 1982.

6. Джини К. Логика в статистике. М.: Статистика,1973. 127 с.

7. Квейд Э. Анализ сложных систем. М.: Советское радио,1969.519 с.

8.Квейд Э. Методы системного анализа // Новое в теории и практике управления производством в США.М.: Прогресс, 1971. с.78-99.

9. Корбут А.А., Финкельштейн Ю. Ю. Дискретное программирование М. Наука. Гл. ред. физ.-мат. лит. 1969.

10.Клыков Ю. И. Ситуационное управление большими системами. М.: Энергия,1974.135 с.

11. Макаров И. М. и др. Теория выбора и принятия решений. М.: Наука, 1982. 328 с.

12.ПфанцагльИ. Теория измерений. М.: Наука, 1988.384 с.

13. Таха Х. А. Введение в исследование операций. 7-е изд. М.: Изд. дом Вильямс, 2005.

14.Фишберн П. С. Теория полезности для принятия решений. М.: Наука,1978. 352 с.

Подробнее..

Новые рекорды найдено 51-ое простое число Мерсенна

21.06.2021 00:15:47 | Автор: admin

(Примечание переводчика: не нашёл публикации (-ий) по данной теме на Хабре.)

Блоуинг Рок, Северная Каролина, 21 декабря 2018 года организация Great Internet Mersenne Prime Search (GIMPS, масштабный Интернет-проект по поиску простых чисел Мерсенна) обнаружила самое большое известное простое число 282589933 - 1, состоящее из 24 863 048 разрядов. Компьютер добровольца Патрика Ляроша вычислил его 7 декабря 2018 года. Патрик один из тысяч, использующих бесплатное ПО GIMPS.

Новое простое число, также известное как M82589933, вычислено перемножением 82 589 933 двоек и вычитанием единицы. Оно превосходит предыдущее рекордное простое число более, чем на полтора миллиона разрядов, в особом классе исключительно редких простых, известных как числа Мерсенна. Это всего пятидесят первое открытое простое число Мерсенна; вычисление каждого последующего становится сложнее. Простые числа Мерсенна названы по имени французского монаха Марина Мерсенна, изучавшего эти числа больше 350 лет назад. Основанная в 1996 году GIMPS обнаружила последние 17 простых чисел Мерсенна. Для поиска этих простых чисел скачивают бесплатную программу, и есть шанс выиграть денежный приз, если повезёт найти новое число. У профессора Криса Колдуэлла есть авторитетный веб-сайт, посвящённый самым большим известным простым числам с замечательной историей простых чисел Мерсенна.

Патрик Лярош 35-летний IT-шник, живущий в Окале, штат Флорида. За своё открытие он получил от GIMPS исследовательскую награду в 3 000 долларов.

Клиентское ПО Prime95 разработано основателем GIMPS Джорджем Уолтманом. Скотт Куровски написал системное ПО PrimeNet, координирующее компьютеры GIMPS. Аарон Блоссер теперь работает системным администратором и при необходимости выполняет обновление и обслуживание PrimeNet. Волонтёры имеют шанс получить вознаграждение в 3 000 или 50 000 долларов, если их компьютер откроет новое простое число Мерсенна. Следующей крупной целью GIMPS является выигрыш учреждённой Electronic Frontier Foundation награды в 150 000 долларов, которая будет вручена за нахождение простого числа со 100 000 000 десятичных разрядов.

Мы признательны за нахождение этого простого числа не только Патрику Лярошу, выполнявшему на своём компьютере ПО Prime95: Уолтману за написанное ПО, Куровски и Блоссеру за их работу с сервером Primenet, а также тысячам добровольцев GIMPS, просеявшим миллионы вариантов чисел. В благодарность всем этим людям официально это открытие приписывается Дж. Пейсу, Дж. Уолтману, С. Куровски, А. Блоссеру и коллегам.

Про Great Internet Mersenne Prime Search

Организация Great Internet Mersenne Prime Search (GIMPS) была сформирована в январе 1996 года Джорджем Уолтмана для нахождения новых мировых рекордов простых чисел Мерсенна. В 1997 году Скотт Куровски обеспечил GIMPS возможность использовать мощь тысяч обычных компьютеров для поиска этих иголок в стоге сена. Большинство участников GIMPS вступило в организацию ради захватывающей возможности обнаружения рекордного, редкого и исторического нового простого числа Мерсенна. Поиск следующих простых чисел Мерсенна уже продолжается. Возможно, существуют и меньше, но пока ненайденные простые, и почти абсолютно точно есть бОльшие, ждущие своего обнаружения. Любой человек с достаточно мощным компьютером может присоединиться к GIMPS и стать охотником за большими простыми числами с возможностью получить денежную награду за своё открытие. Всё необходимое ПО можно бесплатно скачать по адресу www.mersenne.org/download/. GIMPS сформирована как Mersenne Research, Inc., некоммерческая научная благотворительная организация 501(с)(3). Подробнее об этом можно прочитать на www.mersenneforum.org и www.mersenne.org; также принимаются добровольные пожертвования.

Дополнительная информация о простых числах Мерсенна

Простые числа давно восхищали и любителей, и профессионалов математики. Целое число больше единицы называется простым числом, если его единственными делителями являются единица и оно само. Первые простые числа: 2, 3, 5, 7, 11 и т.д. Например, число 10 не является простым, потому что делится на 2 и 5. Простое число Мерсенна это простое число, имеющее вид 2P 1. Первыми простыми числами Мерсенна являются 3, 7, 31 и 127, соответствующие P = 2, 3, 5 и 7. Пока известно 50 простых чисел Мерсенна. Простые числа Мерсенна были в центре внимания теории чисел с тех пор, когда их впервые рассмотрел Евклид около 350 до нашей эры. Человек, именем которого назвали эти числа, французский монах Марин Мерсенн (1588-1648 гг.), создал знаменитую гипотезу о том, при каких значениях P можно получить простое число. Чтобы подтвердить эту гипотезу, потребовались 300 лет и несколько важных открытий. Сегодня есть мало практических применений этого простого числа, что заставляет некоторых задаваться вопросом: Зачем вообще искать такие большие простые числа? Подобные сомнения существовали и несколько десятилетий назад, пока наконец не были разработаны важные криптографические алгоритмы на основе простых чисел. Ещё семь хороших причин для поиска больших простых чисел изложены здесь. Предыдущие открытия простых чисел Мерсенна в рамках GIMPS были совершены участниками из разных стран.

Евклид доказал, что каждое простое число Мерсенна генерирует совершенное число. Совершенное число это число, сумма собственных делителей которого равно самому числу. Самым малым совершенным числом является 6 = 1 + 2 + 3, вторым 28 = 1 + 2 + 4 + 7 + 14. Эйлер (1707-1783 гг.) доказал, что все чётные совершенные числа являются результатом простых чисел Мерсенна. Последнее открытое совершенное число это 277232916 x (277232917-1). Это число имеет более 49 миллионов разрядов! Всё ещё неизвестно, существуют ли нечётные совершенные числа.

Арифметические алгоритмы, лежащие в основе проекта GIMPS, имеют уникальную историю. Программы, нашедшие последние большие простые числа Мерсенна, основаны на специальном алгоритме. В начале 1990-х ныне покойный Ричард Крэндэлл, выдающийся учёный из Apple, обнаружил способы удвоения скорости выполнения свёрток очень больших операций умножения. Этот метод применим не только ко поиску простых чисел, но и к другим аспектам вычислений. В процессе работы над этим проектом он также запатентовал систему шифрования Fast Elliptic Encryption, которая теперь принадлежит Apple Computer. В ней для быстрой шифровки и дешифровки сообщений используются простые числа Мерсенна. Джордж Уолтман реализовал алгоритм Крэндэлла на языке ассемблера, создав таким образом программу поиска простых чисел с беспрецедентной эффективностью. Эта работа привела к созданию успешного проекта GIMPS.

Школьные учителя используют GIMPS, чтобы заинтересовать своих учеников математикой. Студенты, запустившие на своих компьютерах ПО, вносят свой вклад в математические исследования.

Подробнее..

Тесла верит своим Богам! Так она находит путь

20.05.2021 10:09:10 | Автор: admin

Как устроена навигация в автомобилях Tesla. В чем трудности поиска пути по земли русской?

C 2018 года все счастливые обладатели Tesla в России получили обновление Европейской навигации в которой России уже не было, официально это объясняется поддержанием баланса веса карт и удалением регионов, не входящих в зону официального обслуживания.

Как же использовать большой экран Tesla на полную силу? Видеть маршрут, какой процент батареи останется? С какой скоростью ехать? Можно ли сделать даунгрейд на старые карты?

Тесла использует для построения маршрутов Valhalla -это механизм маршрутизации с открытым исходным кодом и сопутствующие библиотеки для использования с данными OpenStreetMap.

Valhalla в Tesla и Тесла в ВальхаллеValhalla в Tesla и Тесла в Вальхалле

Вальхалла - это не только пантеон германских Богов и "чертог мёртвых ", но и отличный движок для построения маршрутов с дополнительными инструментами и модульной структурой, API на основе C++, с возможностью перекрестной компиляции различных фрагментов. И да, все это open source https://github.com/valhalla/valhalla.

Работает на Linux и Mac OS и частично на Windows.

Valhalla состоит из нескольких библиотек, каждая из которых отвечает за свою функцию. Расположение различных функций по библиотекам выглядит следующим образом:

Midgard - базовые географические и геометрические алгоритмы для использования в различных других проектах.

Baldr - базовые структуры данных для доступа и кэширования данных маршрута.

Sif - библиотека, используемая при расчете стоимости узлов графа. Это может быть использовано в качестве входных данных для Loki и Thor.

Skadi - библиотека и сервис для доступа к данным о высоте. Это может быть использовано в качестве входных данных для Mjolnir или в качестве автономной службы.

Mjolnir - Инструменты для превращения открытых данных в части графа Valhalla.

Loki - библиотека, используемая для поиска участка графа и корреляции входных местоположений с объектом внутри участка. Эта коррелированная сущность (ребро или вершина) может использоваться в качестве входных данных для Thor.

Meili - библиотека, используемая для сопоставления карт.

Thor - библиотека, используемая для создания пути через иерархию участков графа. Этот путь и атрибуция вдоль пути могут быть использованы в качестве входных данных для Odin.

Odin - библиотека, используемая для создания маневров в пути. Этот набор информации о направлениях может использоваться в качестве входных данных для Tyr.

Tyr - сервис, используемый для обработки http-запросов для маршрута, связывающегося со всеми другими API valhalla. Tyr форматирует вывод из Odin.

Установка

Если у Вас Ubuntu 20.04 отличный гайд по установке.

Здесь можно скачать карты, выбрав нужные регионы.

Для ЦФО РФ

curl -O http://download.geofabrik.de/russia/central-fed-district-latest.osm.pbf

Рендерим карты

valhalla_build_tiles -c ./conf/valhalla.json central-fed-district-latest.osm.pbf

Запускаем

valhalla_service ~/valhalla/scripts/conf/valhalla.json 2

Давайте найдем маршрут на автомобиле из Москвы в Подольск

curl http://localhost:8002/route \--data '{"locations":[              {"lat":55.7522,"lon":37.6156},              {"lat":55.4242,"lon":37.5547}           ],         "costing":"auto"        }' | jq '.'

В ответ получаем JSON с узловыми токами маневров.

Файл навигации в Тесла

Я обратился https://teesla.ru/ и мне передали файл с европейской навигацией из Тесла. Весит файл около 8гб и на мое удивление содержит вовсе не карты, а уже проложенные пути.

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

Пример

json { "trip": { "language": "en-US", "status": 0, "units": "miles", "status_message": "Found route between points", "legs": [ { "shape": "yx{xmA_lybd@oClBqWxRqWhRsFlEeKlHaChBiGbFqGtEkWxRyQbN", "summary": { "max_lon": 19.461329, "max_lat": 41.321014, "time": 28, "length": 0.178, "min_lat": 41.318813, "min_lon": 19.45956 }, "maneuvers": [ { "travel_mode": "drive", "begin_shape_index": 0, "length": 0.154, "time": 24, "type": 1, "end_shape_index": 9, "instruction": "Drive northwest on Rruga Stefan Kaulini.", "verbal_pre_transition_instruction": "Drive northwest on Rruga Stefan Kaulini for 2 tenths of a mile.", "travel_type": "car", "street_names": [ "Rruga Stefan Kaulini" ] }, { "travel_type": "car", "travel_mode": "drive", "verbal_pre_transition_instruction": "Continue on Rruga Glaukia for 100 feet. Then You will arrive at your destination.", "verbal_transition_alert_instruction": "Continue on Rruga Glaukia.", "length": 0.024, "instruction": "Continue on Rruga Glaukia.", "end_shape_index": 10, "type": 8, "time": 4, "verbal_multi_cue": true, "street_names": [ "Rruga Glaukia" ], "begin_shape_index": 9 }, { "travel_type": "car", "travel_mode": "drive", "begin_shape_index": 10, "time": 0, "type": 4, "end_shape_index": 10, "instruction": "You have arrived at your destination.", "length": 0, "verbal_transition_alert_instruction": "You will arrive at your destination.", "verbal_pre_transition_instruction": "You have arrived at your destination." } ] } ], "summary": { "max_lon": 19.461329, "max_lat": 41.321014, "time": 28, "length": 0.178, "min_lat": 41.318813, "min_lon": 19.45956 }, "locations": [ { "original_index": 0, "lon": 19.461336, "lat": 41.318817, "type": "break" }, { "original_index": 1, "lon": 19.459599, "lat": 41.320999, "type": "break" } ] } }

Для адресов используются данные из карт Tomtom

Пример импорта в файле карт tesla из tomtom

mport_db:schema tomtom_eur_2019_03_007:eur_schema_0329export_db:schema tomtom_eur_2019_03_007:allagash_eur_schema_0329_02_05_2019_a665978_10482

EU-2019.20-10482valhalla_allagash_eur_schema_0329_02_05_2019_a665978_10482_02_05_2019_a665978_10482.pbf-tiles-1ee14c0.tarimport a665978export a665978build 1ee14c0 VE-3.0.0 common pro/dad pro/dun pro/eng pro/frf pro/ged pro/iti high/non pro/spe pro/swsaddress-eur-tomtom_eur_2019_03_007-19.mt./valhalla/build-filesync.shcbe7391137bb Fri May 3 23:42:49 UTC 2019import_db:schema tomtom_eur_2019_03_007:eur_schema_0329export_db:schema tomtom_eur_2019_03_007:allagash_eur_schema_0329_02_05_2019_a665978_10482supplement

Файл карт в файловой системе Squashfs (.sfs)

Последние 2кб очень странные, в них и вся соль. Файлы подписаны ключом. Шифрование AES.

При загрузке карт в машину, Тесла проверяет подпись поэтому модифицированные карты не удалось загрузить.

P.S.

Можно ли подписать карты? Найти ключ и порядок S-box? Тесла на Тегра хранят файл навигации на отдельной карте памяти в MCU. Тесла на Intel хранят файл навигации на в основной eMMC. С картой памяти все просто, разбираем половину торпеды, вытаскиваем из MCU, заливаем дамп с картами и вставляем обратно, с eMMC не так все однозначно. Если карты просто залить на чип eMMC, апдейтер в автомобиле с живыми сертификатами загрузит обновление и заменит их.

От cебя готов предоставить приз целый день аренды самой заряженной Tesla model 3 Performance за способ генерации и загрузки карт в Tesla model 3 с РФ. Пишите в личку.

Подробнее..

Перевод Как использовать Python для проверки протокола Signal

08.06.2021 18:13:14 | Автор: admin

Galois работает над повышением удобства SAW, инструмента для верификации программ наCиJava, исходный код кторого открыт. Основным способом взаимодействия пользователей сSAW является его спецификация иязык программирования сценариев. Чтобы сделать SAW как можно более доступным, вкачестве языка программирования SAW теперь можно использовать Python! Для демонстрации этой новой возможности в Galoisсоздали пример, выполнив проверку части реализации протокола Signal наязыкеС.В частности, как спецификация SAW определяются условия, при которых сообщение протокола Signal будет успешно аутентифицировано. К старту курса о Fullstack-разработке на Python мы перевели материал об этом примере.


SAW-клиент Python

Управление SAW может осуществляться средствами Python через библиотеку saw-client вPyPI. Реализация спомощью Python непредставляет сложности управление SAW осуществляется через JSON-RPC API, как показано впредыдущей статье. Библиотека saw-client постоянно развивалась, итеперь вней реализован высокоуровневый интерфейс, отвечающий зареализацию функций RPC.

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

Сдругой стороны, Python широко используемый язык, изначально хорошо знакомый гораздо большему числу людей. УPython также имеется богатый набор библиотек ивспомогательных программ, доступных вкаталоге PyPI. Даже если Python невходит вчисло ваших любимых языков программирования, мывсё равно советуем попробовать saw-client. Если под рукой неокажется ничего другого, код, написанный вsaw-client, может послужить источником вдохновения для реализации аналогичного клиента надругом языке.

Базовая спецификация вsaw-client

Давайте рассмотрим, как saw-client можно использовать для создания спецификаций реального кода наязыкеC. Для примера возьмём libsignal-protocol-c. Эта библиотека представляет собой реализованный наязыке Cпротокол Signal, криптографический протокол, используемый для шифрования мгновенных сообщений, голосовых ивидеозвонков. Этот протокол применяется вприложении Signal Messenger, получившем название попротоколу, нотакже поддерживается вдругих приложениях, таких как WhatsApp, Facebook Messenger иSkype.

Общее описание возможностей SAW сиспользованием библиотеки libsignal-protocol-c приведено вразделе "Планы".

Для начала рассмотрим базовую структуру данных, используемую библиотекой libsignal-protocol-c, аименно signal_buffer:

struct signal_buffer {    size_t len;    uint8_t data[];};

signal_buffer представляет собой байтовый массив (массив данных) сдлинойlen. При отправке сообщения спомощью libsignal-protocol-c основным компонентом сообщения является signal_buffer.

Чтобы быть уверенным, что libsignal-protocol-c работает так, как заявлено, нужно убедиться, что содержимое signal_buffer сообщения соответствует ожидаемому. Библиотека проверяет соответствие двух буферов signal_buffer спомощью функции signal_constant_memcmp:

int signal_constant_memcmp(const void *s1, const void *s2, size_t n){    size_t i;    const unsigned char *c1 = (const unsigned char *) s1;    const unsigned char *c2 = (const unsigned char *) s2;    unsigned char result = 0;    for (i = 0; i < n; i++) {        result |= c1[i] ^ c2[i];    }    return result;}

Интуитивно понятно, что утилита signal_constant_memcmp должна проверить, одинаковоли содержимое двух байтовых массивов signal_buffer. Если они одинаковы, функция вернёт значение0. Если содержимое несовпадает, возвращается значение, указывающее набайты, вкоторых массивы отличаются.

При этом напервый взгляд может быть неочевидно, что при одинаковых массивах функция вернёт значение0. Учитывая, что манипуляций сбитами происходит довольно много, вполне возможно, что кто-то мог допустить ошибку при написании кода, манипулирующего битами. Правильность такого кода можно проверить, сверив его соспецификацией, созданной спомощью saw-client. Такая спецификация может выглядеть примерно так:

from saw_client.llvm import *class ConstantMemcmpEqualSpec(Contract):    def specification(self) -> None:        _1        self.execute_func(_2)        _3

Класс Contract определяет спецификации SAW сиспользованием метода specification. Чтобы создать собственную спецификацию, достаточно создать подкласс Contract ипереопределить метод specification. Каждая спецификация состоит изтрёх частей:

  • Предварительные условия (_1), определяющие допущения, которые необходимо сделать перед вызовом верифицируемой функции.

  • Аргументы для передачи впроверяемую функцию (_2).

  • Постусловия (_3), определяющие характер проверки после вызова верифицируемой функции.

Учитывая требования кспецификации, проверим, как утилита signal_constant_memcmp работает в пределах спецификации SAW:

class ConstantMemcmpEqualSpec(Contract):    n: int    def __init__(self, n: int):        super().__init__()        self.n = n    def specification(self) -> None:        s1  = self.fresh_var(array_ty(self.n, i8), "s1")        s1p = self.alloc(array_ty(self.n, i8), points_to = s1)        s2  = self.fresh_var(array_ty(self.n, i8), "s2")        s2p = self.alloc(array_ty(self.n, i8), points_to = s2)        self.precondition(cryptol(f"{s1.name()} == {s2.name()}"))        self.execute_func(s1p, s2p, cryptol(f"{self.n} : [64]"))        self.returns(cryptol("0 : [32]"))

Предварительными условиями являются наличие двух байтовых массивов (s1p иs2p), содержимое которых s1 иs2одинаково. Вчастности, одинаковость содержимого гарантирует вызов self.precondition(...). Аргумент self.precondition(...) записывается наCryptol, предметно-ориентированном языке программирования (DSL), используемом вкриптографии. Приведённое выражение наCryptol довольно простое, так как выполняет только проверку равенства, нониже мыувидим более сложные примеры наCryptol.

Аргументами функции являются два байтовых массива суказанием ихдлин (self.n), преобразуемых вначале ввыражение Cryptol, чтобы SAW мог получить оних представление. Порстусловие, снова ввиде выражения наCryptol, заключается втом, что функция возвращает значение 0.

После проведения всей подготовительной работы проверяем, что signal_constant_memcmp соответствует созданной нами спецификации:

mod = llvm_load_module("libsignal-protocol-c.bc") # An LLVM bitcode filearray_len = 42 # Pick whichever length you want to checkllvm_verify(mod, "signal_constant_memcmp", ConstantMemcmpEqualSpec(array_len))

Если проверка пройдёт нормально, можно запустить этот код наPython иувидеть следующий результат:

Verified: lemma_ConstantMemcmpEqualSpec (defined at signal_protocol.py:122)

Ура! Инструмент SAW проверил правильность работы утилиты signal_constant_memcmp. Важно отметить, что нам ненужно было даже упоминать обитовых манипуляциях внутри функции SAW выполнил ихавтоматически. Отметим, однако, что команда ConstantMemcmpEqualSpec определяет происходящее только втом случае, если байтовые массивы равны друг другу. Еслибы мыхотели охарактеризовать происходящее вслучае неравенства байтовых массивов, потребоваласьбы несколько более сложная спецификация.

Также следует отметить, что вприведённом выше коде встречаются повторения, так как мыдважды вызываем функцию self.fresh_var(), азатем self.alloc(). Ксчастью, Python избавляет оттаких проблем:

def ptr_to_fresh(spec: Contract, ty: LLVMType,                 name: str) -> Tuple[FreshVar, SetupVal]:    var = spec.fresh_var(ty, name)    ptr = spec.alloc(ty, points_to = var)    return (var, ptr)class ConstantMemcmpEqualSpec(Contract):    ...    def specification(self) -> None:        (s1, s1p) = ptr_to_fresh(self, array_ty(self.n, i8), "s1")        (s2, s2p) = ptr_to_fresh(self, array_ty(self.n, i8), "s2")        ...

Верификация кода сиспользованием HMAC

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

Одним изосновных этапов шифрования сообщения является присоединение кода аутентификации сообщения (MAC), который можно использовать для проверки того, что после отправки сообщения его содержимое неменялось. Вчастности, libsignal-protocol-c использует HMAC, тип MAC, вычисляемый спомощью криптографической хеш-функции.

Подробное описание работы HMAC тема для отдельной статьи. Но, ксчастью, для создания спецификации SAW, связанной сHMAC, ненужно вдаваться вдетали. Вместо этого можно использовать неинтерпретируемые функции. Для начала создадим ряд функций Cryptol, определяющих характер работы HMAC:

hmac_init : {n} [n][8] -> HMACContexthmac_init = undefinedhmac_update : {n} [n][8] -> HMACContext -> HMACContexthmac_update = undefinedhmac_final : HMACContext -> [SIGNAL_MESSAGE_MAC_LENGTH][8]hmac_final = undefined

Это будут неинтерпретируемые функции, используемые для создания кода, связанного сHMAC, вбиблиотеке libsignal-protocol-c. Основная идея заключается втом, что, получив навходе криптографический ключ, hmac_init создаст HMACContext. HMACContext будет многократно обновляться через hmac_update, используя данные первого аргумента. Затем hmac_final преобразует HMACContext вsignal_buffer достаточной длины для хранения MAC.

Определение HMACContext зависит оттого, какая криптографическая хэш-функция используется всочетании сHMAC. Параметры библиотеки libsignal-protocol-c настроены для используемых еюхеш-функций, поэтому можно свободно подключать библиотеки OpenSSL, Common Crypto или другую подходящую библиотеку.

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

После определения этих функций можно связать ихссоответствующими функциями Cвсамой библиотеке. Например, вот сокращённая спецификация для функции signal_hmac_sha256_initC:

class SignalHmacSha256InitSpec(Contract):    key_len: int    def specification(self) -> None:        hmac_context_ptr = self.alloc(...)        (key_data, key)  = ptr_to_fresh(self, array_ty(self.key_len, i8),                                        "key_data")            self.execute_func(..., hmac_context_ptr, key,                          cryptol(f"{self.key_len} : [64]"))        init = f"hmac_init`{{ {self.key_len} }} {key_data.name()}"        dummy_hmac_context = self.alloc(..., points_to = cryptol(init))        self.points_to(hmac_context_ptr, dummy_hmac_context)        self.returns(cryptol("0 : [32]"))key_len = 32init_spec = llvm_assume(mod, "signal_hmac_sha256_init",                        SignalHmacSha256InitSpec(key_len))

Нестарайтесь понять каждую строчку кода. Просто знайте, что самой важной его частью является последняя строка, вкоторой вместо llvm_verify используется llvm_assume. Функция llvm_assume позволяет SAW использовать спецификацию, фактически немоделируя её посути SAW трактует еёкак аксиому. Это позволяет привязать поведение signal_hmac_sha256_init кнеинтерпретируемой функции hmac_init впостусловиях спецификации.

Аналогичным образом llvm_assume также можно использовать для создания спецификаций, включающих hmac_update иhmac_final. После этого можно проверить очень важную функцию, связанную сMAC: signal_message_verify_mac. Фактически данная функция принимает сообщение вкачестве аргумента, вычисляет MAC для данных внутри сообщения ипроверяет, совпадаетли онсMAC вконце сообщения. Если значения совпадают, можно суверенностью утверждать, что при отправке получателю сообщение неменялось.

Объяснение всех тонкостей работы signal_message_verify_mac занялобы довольно много времени, поэтому вэтой заметке мыкоснёмся лишь главного вопроса: как должно выглядеть содержимое сообщения? Данные внутри сообщения могут быть произвольными, однако MAC вконце должен иметь вполне определённую форму. Эту форму можно определить спомощью функции Python:

def mk_hmac(serialized_len: int, serialized_data: FreshVar,        receiver_identity_key_data : FreshVar,        sender_identity_key_data: FreshVar,        mac_key_len: int, mac_key_data: FreshVar) -> SetupVal:    sender_identity_buf = f"""        [{DJB_TYPE}] # {sender_identity_key_data.name()}            : [{DJB_KEY_LEN} + 1][8]        """    receiver_identity_buf = f"""        [{DJB_TYPE}] # {receiver_identity_key_data.name()}            : [{DJB_KEY_LEN} + 1][8]        """    hmac = f"""        hmac_final         (hmac_update`{{ {serialized_len} }} {serialized_data.name()}          (hmac_update`{{ {DJB_KEY_LEN}+1 }} ({receiver_identity_buf})           (hmac_update`{{ {DJB_KEY_LEN}+1 }} ({sender_identity_buf})            (hmac_init`{{ {mac_key_len} }} {mac_key_data.name()}))))        """    return cryptol(hmac)

Довольно сложно, неправдали? Ноещё раз нестарайтесь понять каждую строчку кода. Тут важно понять, что сначала вызывается hmac_init, затем выполняются несколько вызовов hmac_update, после чего осуществляется вызов hmac_finalcall. Это весьма близко интуитивным допущениям, сделанным ранее для HMAC, поэтому, если SAW убедится втом, что MAC выглядит как данное выражение Cryptol, можно быть уверенным, что онработает так, как ожидалось.

Далее нам нужно использовать это вспецификации. Вот выдержка изспецификации для signal_message_verify_mac, вкоторой впредусловиях описывается, как должно выглядеть валидное сообщение:

lass SignalMessageVerifyMacSpec(Contract):    serialized_len: int    def specification(self) -> None:        ...        mac_index = 8 + self.serialized_len - SIGNAL_MESSAGE_MAC_LENGTH        ser_len   = f"{self.serialized_len} : [64]"        self.points_to(serialized[0], cryptol(ser_len))        self.points_to(serialized[8], serialized_message_data)        self.points_to(serialized[mac_index], mk_hmac(...))        self.execute_func(...)        self.returns(cryptol("1 : [32]"))

Здесь serialized указывает наsignal_buffer для всего сообщения. Для описания памяти, содержащейся вразличных частях буфера, можно использовать нотацию слайса Python (например, serialized[0]). Первая часть содержит self.serialized_len, общую длину сообщения. Через восемь байтразмещается serialized_message_data данные сообщения. Всамом конце буфера содержится MAC, вычисленный спомощью mk_hmac(...).

Проверяем всё напрактике вызываем llvm_verify согласно этой спецификации. Вэтот раз нужно передать несколько дополнительных аргументов. Нужно явно указать, какие допущения мысделали ранее спомощью llvm_assume посредством аргумента lemmas. Также нужно указать инструменту решения SMT, какие функции должны рассматриваться как неинтерпретируемые. Это делается спомощью аргумента script:

uninterps = ["hmac_init", "hmac_update", "hmac_final"]llvm_verify(mod, "signal_message_verify_mac",  SignalMessageVerifyMacSpec(...),            lemmas=[init_spec, update_spec1, update_spec2, final_spec],            script=ProofScript([z3(uninterps)]))

В результате мы видим долгожданную зелёную галочку:

Планы

Спомощью saw-client мысмогли получить ряд интересных данных окоде вlibsignal-protocol-c. Мысмогли продемонстрировать, что signal_message_verify_mac, функция, проверяющая целостность сообщения, отправленного попротоколу Signal, работает правильно, если последняя часть сообщения содержит верный код аутентификации сообщения (MAC). Кроме того, мыопределили, каким должно быть содержимое MAC относительно абстрактной спецификации криптографических хэш-функций.

Однако спомощью инструмента saw-client можно сделать гораздо больше, чем рассказано вданной заметке. Мыпроверяли ключевое свойство кода, проверяющего целостность сообщений. Нотакая проверка целостности некасалась сообщений, передаваемых попроводам. Мытакже нестали полностью определять поведение HMAC, хотя это можно былобы сделать; смотрите здесь.

Несмотря нато что saw-client может использоваться как самостоятельный инструмент верификации, внекоторых аспектах saw-client недостигает функциональности SAWScript. saw-client внастоящее время неподдерживает ряд функций SAW, например функцию инициализации глобальных переменных вспецификациях. Кроме того, некоторые идиомы SAWScript реализованы вsaw-client нетак "красиво", пример квазикавычки ввыражениях Cryptol. Мысчитаем, что современем нам удастся решить эти проблемы.

Вперспективе мыпопытаемся сделать Python полноправным языком написания кода для SAW, иданная работа первый шаг вэтом направлении. Весь код, представленный вэтой заметке, можно найти здесь. Рекомендуем испытать вработе инструмент saw-client. Любые ваши пожелания икомментарии отправляйте в трекер проблем ивопросов SAW.

А если вам инетересен не только анализ программ с помощью Python, но и активная разработка на этом языке в направлениях как бекенда, так и фронтенда, то вы можете обратить внимание на наш курс "Fullstack-разработчик на Python", где также рассматривается тестирование ПО и многие другие аспекты профессии программиста.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Acme.sh Ansible Alias mode Автоматизируем получение и распространение TLS сертификатов

09.06.2021 20:16:20 | Автор: admin

Acme.sh - скрипт, позволяющий без особых проблем получать let's encrypt сертификаты очень разными способами. В данной статье я разберу как получать сертификаты через DNS api, но этим уже никого не удивишь, поэтому расскажу про метод DNS alias, он свежий (всего 3 года) и интересный. А так же про автоматизацию на Ansible и немного про мониторинг сертификатов.

Видеоверсия

Режимы acme.sh получения сертификатов прямо на целевом сервере

  • Webroot

  • Nginx\Apache

  • Stanalone

Режимы хорошие и удобные, когда у вас один - два сервера и можно просто на каждый установить acme.sh. Когда количество серверов, которым нужно TLS, переваливает за десяток, удобнее начать использовать wilcard сертификаты и выделить отдельный сервер для получения и распространения сертификата\ов. Получить wildcard сертификат можно только через подтверждение владения DNS зоной. DNS режимов несколько:

  • DNS manual

  • DNS API

  • DNS alias

Все примеры буду показывать на моём личном домене и установленном локально acme.sh.

DNS manual mode

Manual режим работает супер просто. Запускаем acme.sh с флагом --dns

acme.sh --issue --dns -d *.itdog.info --yes-I-know-dns-manual-mode-enough-go-ahead-please

koala@x220:~$ acme.sh --issue --dns -d *.itdog.info --yes-I-know-dns-manual-mode-enough-go-ahead-please[Ср мая  5 14:52:29 MSK 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory[Ср мая  5 14:52:29 MSK 2021] Creating domain key[Ср мая  5 14:52:29 MSK 2021] The domain key is here: /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key[Ср мая  5 14:52:29 MSK 2021] Single domain='*.itdog.info'[Ср мая  5 14:52:29 MSK 2021] Getting domain auth token for each domain[Ср мая  5 14:52:32 MSK 2021] Getting webroot for domain='*.itdog.info'[Ср мая  5 14:52:32 MSK 2021] Add the following TXT record:[Ср мая  5 14:52:32 MSK 2021] Domain: '_acme-challenge.itdog.info'[Ср мая  5 14:52:32 MSK 2021] TXT value: 'QXRgFOfVOZGOBC1qxAToMNOf7Xsv9gjM8hYG6akRoJ8'[Ср мая  5 14:52:32 MSK 2021] Please be aware that you prepend _acme-challenge. before your domain[Ср мая  5 14:52:32 MSK 2021] so the resulting subdomain will be: _acme-challenge.itdog.info[Ср мая  5 14:52:32 MSK 2021] Please add the TXT records to the domains, and re-run with --renew.[Ср мая  5 14:52:32 MSK 2021] Please add '--debug' or '--log' to check more details.[Ср мая  5 14:52:32 MSK 2021] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh

--issue - запрос на получение

--dns без аргумента - режим ручного DNS

--yes-I-know-dns-manual-mode-enough-go-ahead-please - интересное решение проблемы, когда люди не понимают что такое ручной режим

Он выдаёт TXT запись, которую нам необходимо добавить в наш dns хостинг, в данном случае это _acme-challenge.itdog.info TXT QXRgFOfVOZGOBC1qxAToMNOf7Xsv9gjM8hYG6akRoJ8

Ручной он потому что, мы вручную добавляем эту запись.

Анимация manual modeАнимация manual mode

После этого добавления нужно подождать какое-то время, что бы запись зарезолвилась и выполнить такую же команду, только с --renew

После добавления записи проверяем начала ли она резолвится на гугловом dns

koala@x220:~$ dig -t txt _acme-challenge.itdog.info @8.8.8.8; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> -t txt _acme-challenge.itdog.info @8.8.8.8;; ANSWER SECTION:_acme-challenge.itdog.info. 1798 IN    TXT    "QXRgFOfVOZGOBC1qxAToMNOf7Xsv9gjM8hYG6akRoJ8"

Она резолвится, а значит можно получать сертификат

koala@x220:~$ acme.sh --renew --dns -d *.itdog.info --yes-I-know-dns-manual-mode-enough-go-ahead-please[Ср мая  5 14:58:08 MSK 2021] Renew: '*.itdog.info'[Ср мая  5 14:58:09 MSK 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory[Ср мая  5 14:58:09 MSK 2021] Single domain='*.itdog.info'[Ср мая  5 14:58:09 MSK 2021] Getting domain auth token for each domain[Ср мая  5 14:58:09 MSK 2021] Verifying: *.itdog.info[Ср мая  5 14:58:13 MSK 2021] Success[Ср мая  5 14:58:13 MSK 2021] Verify finished, start to sign.[Ср мая  5 14:58:13 MSK 2021] Lets finalize the order.[Ср мая  5 14:58:13 MSK 2021] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/121...'[Ср мая  5 14:58:15 MSK 2021] Downloading cert.[Ср мая  5 14:58:15 MSK 2021] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/042...'[Ср мая  5 14:58:16 MSK 2021] Cert success.-----BEGIN CERTIFICATE-----certificate-----END CERTIFICATE-----[Ср мая  5 14:58:16 MSK 2021] Your cert is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.cer [Ср мая  5 14:58:16 MSK 2021] Your cert key is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key [Ср мая  5 14:58:16 MSK 2021] The intermediate CA cert is in  /home/koala/.acme.sh/*.itdog.info/ca.cer [Ср мая  5 14:58:16 MSK 2021] And the full chain certs is there:  /home/koala/.acme.sh/*.itdog.info/fullchain.cer 

После этого TXT запись можно удалить.

Теперь есть ключ и сертификат, который будет действителен 3 месяца. Обновить сертификат можно будет через 2 месяца, let's enctypt даёт запас времени и если у вас вдруг что-то сломается, будет целый месяц чтобы починить и обновить сертификат.

И да, обновляется только сертификат, ключ остаётся таким, какой был выдан в первый раз. Обратите внимание на даты создания файлов, особенно *.example.com.key

# ls -l --time-style=+%Y-%m-%d \*.example.com/total 28-rw-r--r-- 1 root root 1587 2021-04-15 ca.cer-rw-r--r-- 1 root root 3433 2021-04-15 fullchain.cer-rw-r--r-- 1 root root 1846 2021-04-15 *.example.com.cer-rw-r--r-- 1 root root  719 2021-04-15 *.example.com.conf-rw-r--r-- 1 root root  980 2021-04-15 *.example.com.csr-rw-r--r-- 1 root root  211 2021-04-15 *.example.com.csr.conf-rw-r--r-- 1 root root 1675 2019-04-10 *.example.com.key

Хороший режим для одного раза или для понимания как работает подтверждение, но на постоянке каждые 2 месяца вручную обновлять TXT записи не серьёзно, поэтому рассматриваем следующий режим.

DNS API mode

Как это работает? Принцип действия тот же самый что у manual, только acme.sh сам вносит и удаляет TXT запись с помощью API вашего dns провайдера.

Анимация API modeАнимация API mode

Под DNS хостингом и DNS провайдером я буду иметь в виду сервис, в который вносятся DNS записи. Это может быть и DNS хостинг, который есть почти у каждой компании, торгующей доменами (namecheap, beget итд) или как отдельный сервис за деньги (Amazon Route 53, ClouDNS итд), или же ваш собственный сервис развернутый с помощью BIND, PowerDNS итд.

У каждого DNS провайдера свой не стандартизированный API и их поддержка в acme.sh реализована отдельными скриптами. Список всех поддерживаемых провайдеров находится тут https://github.com/acmesh-official/acme.sh/wiki/dnsapi

Для каждого написано как пользоваться и пример. Если вашего провайдера или сервиса нет в списке, можно написать свой скрипт, но не спешите открывать vim, дождитесь третьего способа.

Работу этого режима покажу на примере хостинга DNS у namecheap.

Для каждого DNS провайдера свои настройки, где-то нужно просто включить API и сгенерировать токен, где-то бывает посложнее, например для namecheap нужно ещё внести IP в allow list. Включаем API и сразу генерируется token, добавляем IP в список.

Теперь на локальной машине нужно настроить доступ к API

export NAMECHEAP_USERNAME="USERNAME"export NAMECHEAP_API_KEY="TOKEN"export NAMECHEAP_SOURCEIP="MY-IP"

Отступление про дополнительные флаги force и test. Будем использовать флаг -f (--force), что бы наши сертификаты генерировались заново, т.к. acme.sh видит уже сгенерированные сертификаты при их наличии не будет заново получать. Можно конечно просто сделать rm -rf ~/.acme.sh/domain/ вместо этого. Так же будем использовать флаг --test, что бы лишний раз не нагружать продакшн сервера let's encrypt. Вот такое сообщение мы получим, если после подтверждения в manual режиме попробуем другой режим.

[Ср мая 5 16:39:31 MSK 2021] *.itdog.info is already verified, skip dns-01.

Команда получения через API выглядит таким образом

acme.sh --issue --dns dns_namecheap -d *.itdog.info --test

Здесь после --dns мы добавляем имя провайдера.

Запускаем acme.sh

Раскрыть
koala@x220:~$ acme.sh --issue --dns dns_namecheap -d *.itdog.info --test[Ср мая  5 16:48:05 MSK 2021] Using ACME_DIRECTORY: https://acme-staging-v02.api.letsencrypt.org/directory[Ср мая  5 16:48:06 MSK 2021] Using CA: https://acme-staging-v02.api.letsencrypt.org/directory[Ср мая  5 16:48:06 MSK 2021] Creating domain key[Ср мая  5 16:48:07 MSK 2021] The domain key is here: /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key[Ср мая  5 16:48:07 MSK 2021] Single domain='*.itdog.info'[Ср мая  5 16:48:07 MSK 2021] Getting domain auth token for each domain[Ср мая  5 16:48:09 MSK 2021] Getting webroot for domain='*.itdog.info'[Ср мая  5 16:48:10 MSK 2021] Adding txt value: nCH4tBWCkSVn76301f2SdJqCAzmtXvzQAB_Ag8hURLo for domain:  _acme-challenge.itdog.info[Ср мая  5 16:48:15 MSK 2021] The txt record is added: Success.[Ср мая  5 16:48:15 MSK 2021] Let's check each DNS record now. Sleep 20 seconds first.[Ср мая  5 16:48:36 MSK 2021] You can use '--dnssleep' to disable public dns checks.[Ср мая  5 16:48:36 MSK 2021] See: https://github.com/acmesh-official/acme.sh/wiki/dnscheck[Ср мая  5 16:48:36 MSK 2021] Checking itdog.info for _acme-challenge.itdog.info[Ср мая  5 16:48:37 MSK 2021] Domain itdog.info '_acme-challenge.itdog.info' success.[Ср мая  5 16:48:37 MSK 2021] All success, let's return[Ср мая  5 16:48:37 MSK 2021] Verifying: *.itdog.info[Ср мая  5 16:48:41 MSK 2021] Success[Ср мая  5 16:48:41 MSK 2021] Removing DNS records.[Ср мая  5 16:48:41 MSK 2021] Removing txt: nCH4tBWCkSVn76301f2SdJqCAzmtXvzQAB_Ag8hURLo for domain: _acme-challenge.itdog.info[Ср мая  5 16:48:46 MSK 2021] Removed: Success[Ср мая  5 16:48:46 MSK 2021] Verify finished, start to sign.[Ср мая  5 16:48:46 MSK 2021] Lets finalize the order.[Ср мая  5 16:48:46 MSK 2021] Le_OrderFinalize='https://acme-staging-v02.api.letsencrypt.org/acme/finalize/193...'[Ср мая  5 16:48:48 MSK 2021] Downloading cert.[Ср мая  5 16:48:48 MSK 2021] Le_LinkCert='https://acme-staging-v02.api.letsencrypt.org/acme/cert/fa62...'[Ср мая  5 16:48:49 MSK 2021] Cert success.-----BEGIN CERTIFICATE-----certificate-----END CERTIFICATE-----[Ср мая  5 16:48:49 MSK 2021] Your cert is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.cer [Ср мая  5 16:48:49 MSK 2021] Your cert key is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key [Ср мая  5 16:48:49 MSK 2021] The intermediate CA cert is in  /home/koala/.acme.sh/*.itdog.info/ca.cer [Ср мая  5 16:48:49 MSK 2021] And the full chain certs is there:  /home/koala/.acme.sh/*.itdog.info/fullchain.cer

В логе прям видно, что acme.sh добавляет TXT запись, ждёт немного, проверяет запись через доверенные DNS сервера, удаляет запись и скачивает сертификаты с ключом.

После первого запуска через API, acme.sh заносит env переменные c доступами к API себе в файл ~/.acme.sh/account.conf и вам не нужно каждый раз их экспортировать.

Отлично, получение автоматизировали, всё вроде классно. Но у этого метода есть свои недостатки:

  • Если никто не написал скрипта для вашего провайдера\сервиса, то нужно либо писать, либо переезжать на другой провайдер

  • А есть ли у вашего провайдера API?

  • Поразмышляем немного об безопасности. Вот у меня в "открытую" лежит полный доступ к редактированию моего домена, если он каким-то образом попадёт в чужие руки, эти руки могут сделать что угодно. Эту проблему можно решить ограничим доступа в API, например по токену можно только добавлять\удалять txt записи _acme-challenge. Есть ли такая возможность у вашего провайдера? Я не встречал такого, наверное есть у какого-нибудь AWS конечно. Обычно уже хорошо если есть API, а токен один и даёт полный доступ

  • У вас несколько доменов на разных провайдерах (сочувствую). Тут конечно можно настроить каждое API и сделать для каждого провайдера отдельный запуск acme.sh со своими переменными, но мне кажется это не очень удобным. Тем более если у одного из них отсутствует API или скрипт

  • Кто-то просто не любит, что бы в DNS постоянно лазил какой-то скрипт и что-то добавлял\удалял

DNS aliase mode

Это модернизированный режим DNS API.

Идея такая: Есть технический домен, через добавления TXT записей на котором мы подтверждаем владение основным доменом. т.е. acme.sh смотрит CNAME запись у основного домена, видит "перенаправление" на технический домен и идёт к нему проверять TXT запись. А дальше всё как в режиме DNS API.

Анимация alias modeАнимация alias mode

Разберём последовательно. Для демонстрации я купил домен tech-domain.club, он выступает в качестве технического домена. В моём примере основной домен itdog.info располагается на namecheap, а техничский tech-domain.club я делегирую на Hetzner DNS, таким образом операции с записями будут производиться через API Hetzner'a.

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

_acme-challenge CNAME _acme-challenge.tech-domain.club

Для провайдера с техническим доменом мы настраиваем доступ к API.

Экспортируем токен Hetzner export HETZNER_Token="TOKEN"

Команда выглядит так (-f и --test опять же для примера)

acme.sh --issue -d *.itdog.info --challenge-alias tech-domain.club --dns dns_hetzner -f --test
Раскрыть
koala@x220:~$ acme.sh --issue -d *.itdog.info -d itdog.info --challenge-alias tech-domain.club --dns dns_hetzner -f --test[Пт мая  7 13:40:11 MSK 2021] Domains have changed.[Пт мая  7 13:40:11 MSK 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory[Пт мая  7 13:40:11 MSK 2021] Multi domain='DNS:*.itdog.info,DNS:itdog.info'[Пт мая  7 13:40:11 MSK 2021] Getting domain auth token for each domain[Пт мая  7 13:40:15 MSK 2021] Getting webroot for domain='*.itdog.info'[Пт мая  7 13:40:15 MSK 2021] Getting webroot for domain='itdog.info'[Пт мая  7 13:40:15 MSK 2021] Adding txt value: Zlrij9n4y5QXfH6yx_PBn45bgmIcT70-JuW2rIUa6lc for domain:  _acme-challenge.tech-domain.club[Пт мая  7 13:40:16 MSK 2021] Adding record[Пт мая  7 13:40:17 MSK 2021] Record added, OK[Пт мая  7 13:40:20 MSK 2021] The txt record is added: Success.[Пт мая  7 13:40:20 MSK 2021] Let's check each DNS record now. Sleep 20 seconds first.[Пт мая  7 13:40:41 MSK 2021] You can use '--dnssleep' to disable public dns checks.[Пт мая  7 13:40:41 MSK 2021] See: https://github.com/acmesh-official/acme.sh/wiki/dnscheck[Пт мая  7 13:40:41 MSK 2021] Checking itdog.info for _acme-challenge.tech-domain.club[Пт мая  7 13:40:42 MSK 2021] Domain itdog.info '_acme-challenge.tech-domain.club' success.[Пт мая  7 13:40:42 MSK 2021] All success, let's return[Пт мая  7 13:40:42 MSK 2021] *.itdog.info is already verified, skip dns-01.[Пт мая  7 13:40:42 MSK 2021] Verifying: itdog.info[Пт мая  7 13:40:46 MSK 2021] Success[Пт мая  7 13:40:46 MSK 2021] Removing DNS records.[Пт мая  7 13:40:46 MSK 2021] Removing txt: Zlrij9n4y5QXfH6yx_PBn45bgmIcT70-JuW2rIUa6lc for domain: _acme-challenge.tech-domain.club[Пт мая  7 13:40:50 MSK 2021] Record deleted[Пт мая  7 13:40:50 MSK 2021] Removed: Success[Пт мая  7 13:40:50 MSK 2021] Verify finished, start to sign.[Пт мая  7 13:40:50 MSK 2021] Lets finalize the order.[Пт мая  7 13:40:50 MSK 2021] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/121...'[Пт мая  7 13:40:52 MSK 2021] Downloading cert.[Пт мая  7 13:40:52 MSK 2021] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/04e...'[Пт мая  7 13:40:53 MSK 2021] Cert success.-----BEGIN CERTIFICATE-----certificate-----END CERTIFICATE-----[Пт мая  7 13:40:53 MSK 2021] Your cert is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.cer [Пт мая  7 13:40:53 MSK 2021] Your cert key is in  /home/koala/.acme.sh/*.itdog.info/*.itdog.info.key [Пт мая  7 13:40:53 MSK 2021] The intermediate CA cert is in  /home/koala/.acme.sh/*.itdog.info/ca.cer [Пт мая  7 13:40:53 MSK 2021] And the full chain certs is there:  /home/koala/.acme.sh/*.itdog.info/fullchain.cer 

CNAME запись удалять не нужно, она будет использоваться при каждом обновлении сертификата. Таким образом, вы можете иметь несколько доменов с настроенной CNAME записью на один технический домен и с его помощью получать сертификаты для всех.

Кстати, если вам нужно в одном файле иметь несколько сертификатов, например и itdog.info и wildcard *.itdog.info, то просто перечислите их с -d, например

acme.sh --issue --challenge-alias tech-domain.club --dns hetzner -d *.itdog.info -d itdog.info

Это правило действует и для других методов.

И так, что даёт нам этот режим:

  • Если у вашего провайдера нет API или лень писать скрипт, возьмите технический домен, делегируйте его на сервис, который поддерживает acme.sh

  • Если у вашего провайдера нет настройки прав для доступа через API, то технический домен тоже выручает. В случае, если наш token утечёт, у злоумышленника будет доступ только к вашему техническому домену, и если вы его используете только для acme.sh, то максимум что сможет сделать злоумышленник - получить ключ и сертификат для вашего домена. Это тоже неприятно и можно использовать, но это совершенно другой уровень угрозы, по сравнению с полным доступом к доменной зоне

  • В ситуации с кучей доменов на одном или нескольких провайдерах, жизнь так же становится проще, когда все они просто имеют CNAME запись

Есть так же режим domain-alias, он даёт возможность использовать не _acme-challenge запись, а кастомную, подробности можно прочитать в документации

Автоматизация получения и распространения сертификатов

Мы получили сертификаты, лежат они у нас красиво в ~/.acme.sh и никак не используются. Надо каким-то образом их распространять на сервера. Далее расскажу, как я это делаю с помощью ansible. Ansible используется и для получения\обновления и для распространения. Сразу предупреждаю, мои плейбуки простые как три копейки и заточены под определенную инфраструктуру. Playbooks, hosts на github.

Мой сервер с ansible, уже имеет доступ ко всем необходимым серверам, на нём установлен acme.sh и реализовано два плейбука, на получение и распространение. Кстати, не забудьте закомментировать acme.sh в crontab, что бы не было лишних запросов и путаницы.

Playbook для получения сертификатов

В vars указывается только технический домен, эта переменная используется несколько раз. Токен от API вынесен в отдельный vars файл, что бы хранить его в зашифрованном виде в git. Task "Date and time" нужен для логирования, что бы понимать когда именно что-то пошло не так. Следующие два плейбука это простой shell, отличаются друг от друга количеством доменов в одном файле сертификата. Всем доменам, которым не нужно сочетать в себе обычный и wildcard домен, идут списком в loop.

Домены, которые должны подходить как для обычного, так и для wildcard идут по втором taks, тоже с помощью loop. Если вам нужно например wilcard вида *.*.itdog.info, то просто добавьте ещё один -d и ещё один subkey в item. Опция ignore_errors необходима, потому что exit code 0 будет только 6 раз за год при обновлении сертификата, в остальное время будут сообщения о том, что сертификат не нужно обновлять, для ansible это ошибка на которой он будет останавливаться.

Для чего плейбук на получение? Ведь в acme.sh и так уже всё настроено!

В одном плейбуке мы собираем всю нашу конфигурацию, доступы и все домены, которым необходим TLS, как минимум, это удобно - не надо копаться конфигах acme.sh. В случае изменения, например, токена, мы просто редактируем его в vars_files, а если нужно добавить ещё один домен\подомен, мы просто добавляем его в loop. Ну и в случае переноса сервера, не нужно переносить ~/.acme.sh, только плейбуки с vars_files взять из git.

Playbook для распространения сертификатов

Здесь нужно писать конечно под вашу инфраструктуру, поэтому повторюсь, показываю это для примера.

Три типа серверов из моей инфраструктуры:

  • tls-hosts - Обычный nginx установленный как пакет из стандартного репозитория

  • tls-hosts-docker - Веб проект с тем же nginx, но уже в docker

  • tls-hosts-docker-rename - Сторонний продукт, в который надо подкладывать сертификат и ключ с определённым именем в определённую директорию (например Harbor, Zabbix)

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

Во втором случае всё плюс-минус так же, но уже нужно сделать docker exec project-nginx -s reolad, т.е. уже другой handler.

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

В моём случае доменов много, пути, по которым сертификаты с ключами хранятся, различаются. Так же есть случаи когда у одного сервера несколько доменов. Что бы была возможность настроить для каждого хоста свой путь и необходимый домен, в hosts для каждого хоста заданы переменные пути и домена.

nginx.itdog.info tls_path=/etc/letsencrypt/*.itdog.info/ DOMAIN=*.itdog.info

Для случаев, когда доменов на сервере несколько, делается два хоста с разными именами и одинаковым ansible_host (Совет, как сделать лучше, приветствуется).

nginx.example.com-1 ansible_host=nginx.example.com tls_path=/etc/letsencrypt/*.example.com/ DOMAIN=example.comnginx.example.com-2 ansible_host=nginx.example.com tls_path=/etc/letsencrypt/*.example.org/ DOMAIN=example.org

Для каждого типа серверов создана своя группа в hosts. Для каждой группы свои немного отличающиеся друг от друга tasks. Для tls-hosts-docker так же добавлена переменная с именем контейнера nginx. А для tls-hosts-docker-rename добавлена переменная, в которой задаётся конечное имя сертификата и ключа.

docker-zabbix.itdog.info tls_path=/root/docker-zabbix/zbx_env/etc/ssl/nginx/ DOMAIN=*.itdog.info CONTAINER=docker-zabbix_zabbix-web-nginx-pgsql_1 cert_name=ssl.crt key_name=ssl.key

Для nginx нужен fullchain и domain.key - копируются только они. Если файлы различаются, происходит копирование и срабатывает handler nginx -s reload. Так же есть проверка, перед тем как зарелоудить nginx, что это файл. У меня один раз был случай, в самом начале пользования acme.sh, скрипт вместо файла с сертификатом создал директорию. Прямо как traefik 1.7 создаёт acme.json директорию, вместо файла. Поэтому я сделал простую проверку. В идеале нужно делать проверку, что сертификат валидный и не просроченный, но для этого требуется иметь на каждом хосте python-pyOpenSSL.

Crontab

23 3 * * * /usr/bin/ansible-playbook /etc/ansible/playbook-get-tls.yml -v >> /var/log/get-tls.log23 4 * * * /usr/bin/ansible-playbook /etc/ansible/playbook-copy-tls.yml -v >> /var/log/copy-tls.log

Можно без проблем вызывать их каждый день, let's encrypt будет вежливо говорить, что пока не нужно обновляться. А когда придёт срок, сертификаты будут обновлены.

Мониторинг сертификатов

Надо следить за тем, что бы сертификаты на доменах обновлялись. Можно мониторить логи получения и распространения, и когда что-то идёт не так - кидать warning в системе мониторинга. Но мы пойдём с одной стороны на минималках, с другой более основательно и ещё помимо этого захватим другие исталяции, например с traefik, который живёт там сам по себе.

Я использую zabbix и скрипт от @selivanov_pavel

Проверим с его помощью мой домен локально

koala@x220 ~/t/acme.sh-test> ./ssl_cert_check.sh expire itdog.info 44341

41 день сертификат на itdog.info будет актуален. Сертификат в let's encrypt обновляется за 30 дней до протухания. А значит, например, если ему осталось жить 10 дней, значит что-то пошло не так и надо идти смотреть.

Темплейт состоит из одного item и одного trigger. Теплейт есть так же на github

ssl_cert_check.sh["expire","{HOST.NAME}","{$TLS_PORT}"]

В item две переменных, первая HOST.NAME берёт имя хоста, предполагается что у нас хост назван по доменному имени. Переменная $TLS_PORT по дефолту 443, но если нужно проверять на нестандартном порту, то записываем значение порта в macros.

Триггер тоже супер простой

{Check tls expire:ssl_cert_check.sh["expire","{HOST.NAME}","{$TLS_PORT}"].last()}<=10

Если полученное значение меньше 10ти - аллерт. Таким образом, мы узнаем если у нас начнут протухать сертификаты и будет 10 дней на починку.

Нормально работает?

Да, acme.sh + DNS API + ansible у меня крутится два года. acme.sh + DNS Alias + ansible крутится пол года. Проблемы возникали только, когда при тестировании доменов забыл отключить crontab и он принёс staging сертификат на прод. Такая проблема решается проверкой на валидность.

Да, в идеале, ansible должен проверять перед копированием, что сертификат валидный и не просроченный. А система мониторинга проверять, помимо expire, валидность сертификатов.

Подробнее..

Улучшаем Кузнечик на Rust

03.05.2021 20:08:12 | Автор: admin

Начало

Порой, простое и красивое решение лучше правильного и выдержанного. Возможно, именно так бы и было, если в жизни всё происходило как в учебниках. На практике же, нужно пройти долгий путь, чтобы создать задуманное.

Отступая от лирики, в данной статье я хочу рассказать заинтересованному читателю про шифрование по ГОСТ, а именно алгоритм Кузнечик, и про то, что стоит обратить внимание на новые и перспективные средства язык Rust.

Хватит отступлений, предлагаю начать!

Что будет в данной статье

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

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

Rust или не Rust?

Rust или C++, Go или Rust, Rust или , на эту тему существует уже довольно много статей, поэтому я ограничусь лишь парочкой слов. Rust сочетает в себе все современные и необходимые для разработки средства, включая многочисленные плюшки, которые нравятся разработчикам. Являясь при этом системным языком, Rust не обладает дополнительным оверхедом в виде сборщика мусора и выполняет максимум оптимизаций на этапе компиляции, а также позволяет писать нативный код для встраиваемых систем.

Я считаю, для данной задачи Rust удовлетворяет требованиям производительности и использования памяти, а также что, он более перспективный и удобный в использовании, чем тот же C++. Это лишь моё субъективное мнение и никого не прошу придерживаться его. К тому же, язык программирования это всего лишь инструмент со своими особенностями, преимуществами и недостатками. Если вы считаете, что это не так рад буду услышать вашу позицию по данному вопросу.

Реализация

Перед тем, как вдаваться в подробности кода было бы не плохо продемонстрировать HelloWorld. Для начала подключим библиотеку kuznechik:

Cargo.toml:

[dependencies]kuznechik = "0.2.0"

Теперь зашифруем и расшифруем строку "Hello World!":

main.rs:

fn hello_world() {    // Инициализация    let gamma = vec![0x12, 0x34, 0x56, 0x78, 0x90, 0xab, 0xce, 0xf0, 0xa1, 0xb2, 0xc3, 0xd4, 0xe5, 0xf0, 0x01, 0x12,                     0x23, 0x34, 0x45, 0x56, 0x67, 0x78, 0x89, 0x90, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19];    let kuz = Kuznechik::new("Кузнечик на Rust").unwrap();    let mut alg = AlgOfb::new(&kuz);    alg.gamma = gamma.clone();        let data = String::from("Hello World!").into_bytes();    // Шифрование    let enc_data = alg.encrypt(data.clone());    println!("Encrypted data:\n{:?}", &enc_data);    // Расшифрование    alg.gamma = gamma;    let dec_data = alg.decrypt(enc_data);    println!(        "Decrypted data:\n{}",        String::from_utf8(dec_data.clone()).unwrap()    );    assert_eq!(dec_data, data);}

В коде, представленном выше для создания объекта Kuznechik используется пароль в виде строки. Функция Kuznechik::new() принимает строку и хеширует её по алгоритму Sha3-256 для получения мастер ключа. Также вы можете напрямую задать мастер ключ, для этого можно воспользоваться функцией Kuznechik::new_with_master_key(). Данная функция принимает массив длиной 256 бит (тип [u8; 32]).

Функции alg.encrypt() и alg.decrypt() принимают на вход и возвращают вектор байтов Vec<u8>. Данные функции принимают во владение входные вектора. В некоторых режимах длина выходного вектора больше входного, связано это с процедурой дополнения.

Обзор библиотеки

Архитектура

Архитектура библиотеки устроена так, что неизменяемые данные ключи, хранятся в структуре Kuznechik, а изменяемые и присущи конкретному режиму шифрования данные в структурах, начинающихся с префикса Alg- (в данном примере - AlgOfb). Это касается и функционального кода. Всё это позволяет создать один экземпляр Kuznechik (единожды развернуть ключи) и использовать разные режимы.

Режимы шифрования

Алгоритм Кузнечик может работать в шести режимах (типы AlgEcb, AlgCtr, AlgOfb, AlgCbc, AlgCfb, AlgMac). В приведённом выше примере представлен режим гаммирования с обратной связью по выходу (OFB). В данном режиме для работы алгоритма требуется гамма, значение которой задаётся через переменную alg.gamma. Необходимо учесть, что данная переменная изменяется в процессе шифрования и для успешного расшифрования требуется установить начальное значение гаммы.

Базовый алгоритм

В этом разделе я покажу, как может выглядеть реализация на Rust. Более подробно вы можете посмотреть в исходниках на GitHub.

Базовый алгоритм шифрования выглядит намного проще чем его описание в стандарте:

pub fn encrypt_block(data: &mut Block128, keys: &[Block128; 10]) {    for i in 0..9 {        tfm_lsx(data, &keys[i]);    }    tfm_x(data, &keys[9]);}

Здесь производится девять итераций LSX-преобразования и затем ещё одну итерацию X-преобразования. Напомню длина блока 128 бит или 16 байт. Тип Block128 именно такого размера, элементы которого имеют тип u8.

Далее LSX-преобразование. Оно состоит из поочерёдного вызова X, S, и L преобразований.

fn tfm_lsx(data: &mut Block128, key: &Block128) {    tfm_x(data, key);    tfm_s(data);    tfm_l(data);}

В свою очередь X-преобразование делает сложение по модулю 2 (проще говоря - XOR) блока данных с ключом:

fn tfm_x(data: &mut Block128, key: &Block128) {    for i in 0..16 {        data[i] ^= key[i];    }}

В S-преобразовании в данные вносится нелинейность для чего к данным применяется подстановка (пи).

fn tfm_s(data: &mut Block128) {    for i in 0..16 {        data[i] = K_PI[data[i] as usize];    }}

L-преобразование производит 16 раз R-преобразование на данными.

fn tfm_l(data: &mut Block128) {    for _ in 0..16 {        tfm_r(data);    }}

И наконец R-преобразование:

fn tfm_r(data: &mut Block128) {    let temp = trf_linear(data);    data.rotate_right(1);    data[0] = temp;}

Данное преобразование лучше всего показать на рисунке. F линейное преобразование, которое соотносит 16 байтам однобайтовый результат, согласно выражению ниже.

Линейное преобразование:

Чтобы не вычислять значение линейного преобразования на каждой итерации L-преобразования, можно вычислить, своего рода, таблицу умножения. Таблица содержит 7 строк и 256 столбцов, что соответствует произведениям в поле Галуа коэффициентов на значения входных данных (произведения входных данных на коэффициент равный 1 нет смысла держать в таблице, т.к. результат равен входным данным).

Вычисление линейного преобразования по такой таблице умножения занимает O(1) времени и требует O(1) памяти, а точнее 7 * 256 = 1792 байта, что не так много для современного компьютера.

Собственно реализация:

fn trf_linear(data: &Block128) -> u8 {  // indexes:  0,  1,   2,   3,   4,   5,   6    // values:  16, 32, 133, 148, 192, 194, 251    let mut res = 0u8;    res ^= MULT_TABLE[3][data[0] as usize];    res ^= MULT_TABLE[1][data[1] as usize];    res ^= MULT_TABLE[2][data[2] as usize];    res ^= MULT_TABLE[0][data[3] as usize];    res ^= MULT_TABLE[5][data[4] as usize];    res ^= MULT_TABLE[4][data[5] as usize];    res ^= data[6];    res ^= MULT_TABLE[6][data[7] as usize];    res ^= data[8];    res ^= MULT_TABLE[4][data[9] as usize];    res ^= MULT_TABLE[5][data[10] as usize];    res ^= MULT_TABLE[0][data[11] as usize];    res ^= MULT_TABLE[2][data[12] as usize];    res ^= MULT_TABLE[1][data[13] as usize];    res ^= MULT_TABLE[3][data[14] as usize];    res ^= data[15];    res}

Что касается сложения в линейном преобразовании, то это всего лишь XOR. Таблицу умножения вы можете посмотреть в исходниках.

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

Про велосипед

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

  • Лицензирование ПО.

  • Качество ПО (безопасность, производительность, требования к памяти и тд.).

  • Интерфейс взаимодействия.

  • Зависимости.

  • Ну и конечно же опыт, который получаешь в процессе разработки.

Продолжение следует

Разместить все свои мысли в одной статье, на мой взгляд, было бы неправильно. Так можно быстро утомиться и потерять интерес к материалу. К тому же мне было бы приятно услышать ваше мнение и рассмотреть общие с вами темы.

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

Отдельное спасибо Chris F за фотографии кузнечика.

Подробнее..

Безопасное хранение ключей от сервиса в I2P

17.05.2021 10:05:59 | Автор: admin

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

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

Образование внутрисетевого адреса I2P

Создавая серверный туннель, который выводит локальный сервис в скрытую сеть, необходимо указать файл с ключами (если указывается несуществующий создается новый файл со случайными ключами).

Файл с ключами содержит криптографические идентификаторы. Всего 391 байт публичной информации и секретные ключи, которые не публикуются. Хеш от блока публичной информации, содержащейся в файле с ключами, образует внутрисетевой адрес.

К полному адресу (391 байт публичной информации) осуществляется привязка как длинных адресов .b32.i2p, так и коротких доменных имен в зоне .i2p, поэтому заданный файл с ключами является критически важным: потеряв его, мы теряем и контроль над адресом. Если злоумышленник развернет с нашим ключом другой серверный туннель, работа изначального скрытого сервиса будет в лучшем случае нарушена, а в худшем злоумышленник сможет выдавать свой ресурс за оригинальный для части пользователей, чей роутер найдет его лизсет первым.

Лизсеты

Серверные конечные точки, то есть скрытые сервисы сети I2P, публикуют информацию о себе на флудфилах, чтобы другие участники сети могли найти их. Эта информация называется лизсетом и включает в себя полный набор криптографических идентификаторов полный адрес (391 байт), а также информацию о входящих туннелях. Поиск лизсета происходит по доменному имени, образованному от ключей. Если флудфил располагает нужным лизсетом, клиент получает информацию для связи с конечной точкой.

Безопасное хранение ключей

I2P имеет концепцию оффлайн-ключей (offline keys), которая позволяет хранить постоянные ключи в надежном месте. Другими словами, основной ключ хранится в безопасном месте, а на сервере используется временный, срок действия которого истекает через заданное количество дней. В случае его компрометации, спустя заданный срок действия, вы с полной уверенностью можете утверждать, что ваш сетевой адрес снова принадлежит только вам.

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

Инструмент для создания временных ключей присутствует в наборе i2pd-tools. Утилита называется offlinekeys и имеет следующий порядок принимаемых параметров: <output file> <keys file> <signature type> <days>. Последние два параметра можно опустить, указав только выходной файл и существующие ключи.

Без явного указания типа подписи, по умолчанию используется ED25519-SHA512 (кодовое обозначение 7), а срок годности равен 365 дням, то есть году. Тип подписи можно указать как в кодовом варианте, так и словом.

После того, как файл с временными ключами создан, его можно выгрузить на сервер и использовать в привычном виде. Главное не забыть обновить ключи вовремя. Также можно написать скрипт, автоматизирующий процесс обновления ключей на удаленном сервере.

Оригинальная статья опубликована в блоге дата-центра ITSOFT.

Подробнее..

Абсолютная приватность сервиса в I2P зашифрованый лизсет

03.05.2021 22:12:52 | Автор: admin

Принцип анонимности I2P заключается в неизвестном месторасположении скрытого сервиса. Каждый скрытый сервис (например, сайт или пользователь, который его посещает) взаимодействует с другими ресурсами исключительно через анонимизирующие туннели. Туннели строятся через роутеры участников сети также, как другие пользователи строят туннели через наш роутер. Такая модель создает множество прямых соединений между I2P-роутерами, в которых нельзя определить на каком роутере начался или закончился тот или иной туннель: тысячи одновременных зашифрованных подключений не дают такой возможности.

Чтобы связаться с любым скрытым сервисом, необходимо получить его лизсет (LeaseSet), который содержит информацию о входных туннелях и криптографических ключах. Для этого все серверные конечные точки, ожидающие подключение, публикуют свои лизсеты на флудфилах (Floodfill) роутерах, выступающих в роли справочной книги или доски объявлений. Несмотря на то, что флудфил получает лишь информацию о первых узлах входных туннелей и криптографические ключи, т.е. никакой компрометирующей информации в лизсете нет, архитектура I2P предусматривает использование зашифрованных лизсетов. Это позволяет скрыть наличие конечной точки (она же скрытый сервис и destination) от возможного мониторинга на флудфилах.

Идентификатор незашифрованного лизсета обычный внутрисетевой адрес скрытого ресурса, только без окончания .b32.i2p. Это позволяет держателям флудфилов видеть в открытом виде адреса ресурсов, которые у них опубликовались. Если вы подняли в I2P личный ресурс и не хотите, чтобы о нем случайно узнал кто-то еще, зашифрованный лизсет специально для вас!

Незашифрованный лизсет на флудфилеНезашифрованный лизсет на флудфиле

Сокрытие идентификатора лизсета в англоязычной терминологии называется blinding (ослепление). Отсюда происходит название адреса скрытого сервиса с зашифрованным лизсетом bb32 blinded-b32. В свою очередь b32 во всех доменах сети является сокращением от названия кодировки base32, которой кодируется информация, образующая домен.

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

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

Ознакомиться с криптографическими подробностями блиндинга, т.е. сокрытием идентификатора лизсета, а также с шифрованием его содержимого, можно в официальном документе. Согласно приведенной документации в зашифрованном лизсете поддерживается два типа подписи: EDDSA_SHA512_ED25519 (тип 7) и REDDSA_SHA512_ED25519 (тип 11), однако настоятельно рекомендуется использовать только второй из приведенных. В случае i2pd нерекомендуемый вариант вовсе не реализован, т.к. считается практически бессмысленным.

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

Минимальная конфигурация туннеля конечной точки типа bb32 (которая иногда почему-то называется b33, что не имеет какой-либо логики) выглядит следующим образом (принципиальны последние две строки):

[SUPER-HIDDEN-SERVICE]type = serverhost = 127.0.0.1port = 8080inport = 80signaturetype = 11i2cp.leaseSetType = 5

Чуть раньше были упомянуты флаги, содержащиеся в первом байте адреса с зашифрованным лизсетом. Все, что нас интересует в контексте данной статьи, это флаг авторизации. Настраивается через дополнительный параметр конфигурации i2cp.leaseSetAuthType. Вкратце: это позволяет сделать доступ к приватному ресурсу еще более контролируемым, создавая список по ключам или парольным фразам для каждого пользователя, а в случае чего убрать конкретный идентификатор из списка, после чего соответствующий пользователь уже не получит лизсет, следовательно, и доступ к ресурсу. Подробнее об этом вы можете узнать из документации (параметры i2cp.leaseSetPrivKey, i2cp.leaseSetClient.dh.nnn, i2cp.leaseSetClient.psk.nnn).

Оригинальная статья опубликована в блоге дата-центра ITSOFT.

Подробнее..

На пути к вершине Магма и Кузнечик на Эльбрусе

17.06.2021 16:13:58 | Автор: admin

В последнее время всё чаще появляются статьи о производительности российских процессоров Эльбрус на различных задачах. Тема криптографии пока что остаётся за кадром, хотя в разное время были упоминания то о высоких возможностях Эльбруса (некий ГОСТ лучше в 9 раз на Эльбрус-4С, чем на Intel Core i7-2600), то о плохой оптимизации компилятора и, соответственно, крайне низкой скорости реализованных алгоритмов (Кузнечик в 100 раз медленнее, чем на Intel?). Предлагаю наконец разобраться, что может Эльбрус, на примере двух ГОСТ алгоритмов симметричного шифрования.

Чтобы статья не вышла слишком большой, будем считать, что читатель имеет общее представление об архитектурах процессоров, в том числе знает об Эльбрусе. Если же нет, на сайте разработчика (компании МЦСТ) есть отличное руководство по программированию и книга об архитектуре в целом. Именно с этих материалов и началось моё знакомство с Эльбрусами. Также отмечу, что в современных процессорах очень много различных механизмов и особенностей, так что в статье буду касаться только тех, которые, на мой взгляд, важны при реализации выбранных алгоритмов.

Что может предложить архитектура Эльбрус

Для выполнения арифметических операций у Эльбруса есть 6 АЛУ (арифметико-логических устройств), способных выполнять операции параллельно. Начиная с версии 5 архитектуры появилась поддержка упакованных (SIMD) инструкций над 128-битными регистрами.

Для хранения промежуточных результатов присутствует большой регистровый файл: суммарно в процедуре можно использовать более 200 (64-битных) регистров общего назначения. Для SIMD вычислений используются те же самые регистры, а не отдельные, как это часто бывает. Соответственно, с 5 версии архитектуры все регистры стали 128-битными.

Задачу симметричного шифрования можно отнести к потоковой обработке массива данных. Для таких ситуаций в Эльбрусе есть механизм асинхронной подкачки данных из памяти APB (Array Prefetch Buffer). Использование этого механизма позволяет вовремя подгружать данные из памяти, не теряя время на кэш-промахи.

Выбор реализаций

Хорошим подходом было бы взять несколько известных реализаций, оптимизировать их под Эльбрус и посмотреть на результаты. Но, с другой стороны, мы говорим о процессоре общего назначения, поэтому можно сэкономить силы и время, предположив, что лучшие результаты можно ожидать от подходов, которые являются самыми быстрыми на других архитектурах.

Правда, о производительности ГОСТ алгоритмов обычно говорят только в контексте семейства x86-64, другие архитектуры мало кого интересуют. Но это не беда: мне показалось, что при знании команд ассемблера x86-64 ознакомиться с набором целочисленных и логических инструкций Эльбруса проще, чем, скажем, с ARM-овым. То есть прослеживаются определённые параллели, особенно, в области SIMD инструкций, и даже прямые аналоги. В остальном, конечно, у них нет ничего общего.

Итак, для Магмы известна эффективная реализация режимов, допускающих параллельную обработку блоков, то есть когда несколько блоков могут шифроваться независимо друг от друга. Это, например, режимы ECB, CTR, MGM. При этом скорость конкурирует с AES, для которого на x86-64 есть аппаратная поддержка. Реализация заточена именно под параллельную обработку, в случае последовательной (режимы с зацеплением) используются другие подходы. Мне интересно добиться максимальной скорости, поэтому я ограничился только случаем параллельной обработки.

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

Тестовые машины

То же самое в текстовом виде

Процессор

Версия арх-ры

Кол-во ядер

Тактовая частота

L1d

L1i

L2

L3

Эльбрус-4С

E2Kv3

4

0.75 ГГц

4 x 64 КБ

4 x 128 КБ

4 x 2 МБ

Нет

Эльбрус-1С+

E2Kv4

1

0.985 ГГц

1 x 64 КБ

1 x 128 КБ

1 x 2 МБ

Нет

Эльбрус-8С

E2Kv4

8

1.2 ГГц

8 x 64 КБ

8 x 128 КБ

8 x 512 КБ

16 МБ

Эльбрус-8СВ

E2Kv5

8

1.55 ГГц

8 x 64 КБ

8 x 128 КБ

8 x 512 КБ

16 МБ

Эльбрус-2С3

E2Kv6

2

2 ГГц

2 x 64 КБ

2 x 128 КБ

2 x 2 МБ

Нет

Эльбрус-16С

E2Kv6

16

2 ГГц

16 x 64 КБ

16 x 128 КБ

8 x 1 МБ

32 МБ

Магма

В случае x86-64 быстрая реализация Магмы опирается на использование расширений AVX и AVX2. При этом учитывается наличие в процессоре нескольких АЛУ и возможность параллельного исполнения до 3 векторных инструкций за один такт. Естественно, планирование параллельного исполнения остаётся на откуп процессора.

В случае же Эльбруса есть возможность явно распланировать параллельное исполнение. Опуская некоторые детали, можно считать, что на 3 и 4 поколении возможно исполнить 6 целочисленных векторных операций над 64-битными регистрами, а начиная с 5 поколения 4 векторных операции уже над 128-битными регистрами.

Для Эльбруса я написал собственную реализацию Магмы. Она использует те же идеи, что и исходная под x86-64, но при этом адаптирована под другой набор инструкций. Рассматривал перспективу написания на ассемблере и даже пробовал, но довольно быстро осознал, что ассемблер у Эльбруса достаточно сложный в плане программирования на нём (например, есть много нюансов по размерам задержек и зависимостям инструкций, которые тяжело учесть вручную). При этом оптимизирующий компилятор делает свою работу действительно хорошо: переставляет инструкции в рамках большого окна и при подборе опций компиляции выдаёт плотность кода, которая не отличается от теоретических оценок на количество инструкций и тактов. Так что я остановился на реализации на языке Си с использованием intrinsic функций для доступа к некоторым инструкциям процессора.

Для измерения скорости был выбран режим ECB. Обычно именно он (или даже его упрощения) используется при сравнении производительности, а скорость других режимов можно оценить на базе полученных результатов, отличия несущественны. Речь идёт о реализации базового алгоритма шифрования, поэтому накладные расходы от смены ключа также не учитываются. Объём данных для замера порядка 1 ГБ. Естественно, шифрование на одном ядре. Для многоядерной машины можно умножить результат на количество ядер и получить близкую к реальности оценку скорости. По крайней мере, во всех сравнениях я видел именно такую зависимость. Полученные результаты в таблице ниже:

То же самое в текстовом виде

Процессор

Скорость на невыровненных данных

Скорость на выровненных данных

Производительность

Эльбрус-4С

116 МБ/с

137 МБ/с

5.2 такт/байт

Эльбрус-1С+

151 МБ/с

179 МБ/с

5.2 такт/байт

Эльбрус-8С

185 МБ/с

220 МБ/с

5.2 такт/байт

Эльбрус-8СВ

402 МБ/с

520 МБ/с

2.8 такт/байт

Эльбрус-2С3

669 МБ/с

670 МБ/с

2.8 такт/байт

Эльбрус-16С

671 МБ/с

672 МБ/с

2.8 такт/байт

Здесь под выровненными данными подразумевается выравнивание по границе 8 байтов для E2Kv3/E2Kv4 и 16 байтов для E2Kv5/E2Kv6. При наличии такого выравнивания (на версиях до 6) работает механизм APB и данные для шифрования эффективно подкачиваются из памяти. При этом с версии 6 APB уже не требует выравнивания данных, поэтому при любом расположении данных достигается максимальная скорость. Для невыровненных данных на предыдущих версиях архитектуры я не провёл достаточно исследований, так что значения в этом столбце таблицы можно считать нижней границей.

Для сравнения приведу результаты из статьи с описанием базовой реализации на Intel Core i3-7100 @ 3.9 ГГц. При использовании AVX 458 МБ/с, 8.1 такт/байт; AVX2 1030 МБ/с, 3.6 такт/байт. Так что по абсолютной скорости Эльбрус достаточно близок к современным процессорам Intel (это при значительной разнице в тактовой частоте!) и превосходит x86-64 с AVX в тактах более чем в 1.5 раза (для 3 и 4 поколения), а x86-64 с AVX2 в 1.3 раза (для 5 поколения).

Кузнечик

По сравнению с Магмой, структура Кузнечика является более сложной. Несмотря на то, что удалось декомпозировать нелинейное преобразование S, техники реализации, основанные на широком использовании SIMD-инструкций, пока что отстают от "классической" реализации со склеенным LS (линейным и нелинейным) преобразованием и таблицей предвычислений размером 64 КБ (упоминается в статье под именами с LS или более простое описание на Хабре).

В случае x86-64 Кузнечик эффективнее всего реализуется с использованием AVX-инструкций (удобно работать со 128-битными регистрами, так как длина блока и размер значений в таблице равны в точности 128 битам). При этом для вычислений адресов в таблице не удаётся воспользоваться эффективной адресацией Scale-Index-Base-Displacement (именование из статьи), так как в качестве Scale нужно значение 16, а максимально возможное 8. На Эльбрусе можно ожидать конкурирующих результатов за счёт большого кэша L1d (64 КБ) и наличия 4 АЛУ, обеспечивающих произвольный доступ к памяти (насколько мне известно, у абсолютного большинства процессоров x86-64 2 порта для загрузки данных).

Как и в случае с Магмой, для Кузнечика я написал отдельную реализацию на Си под Эльбрус, чтобы добиться максимальных результатов. Начиная с 5 версии архитектуры я явным образом использовал тип __v2di (см. e2kintrin.h в составе компилятора), чтобы быть уверенным, что получится использовать регистры как 128-битные.

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

Итак, в случае строго последовательной обработки данных:

То же самое в текстовом виде

Процессор

Скорость на невыровненных данных

Скорость на выровненных данных

Производительность

Эльбрус-4С

52 МБ/с

69 МБ/с

10.4 такт/байт

Эльбрус-1С+

63 МБ/с

90 МБ/с

10.4 такт/байт

Эльбрус-8С

80 МБ/с

110 МБ/с

10.4 такт/байт

Эльбрус-8СВ

95 МБ/с

150 МБ/с

9.9 такт/байт

Эльбрус-2С3

170 МБ/с

171 МБ/с

11 такт/байт

Эльбрус-16С

171 МБ/с

172 МБ/с

11 такт/байт

Для сравнения результаты из статьи (лучшие из опубликованных) на Intel Core i7-6700 @ 4 ГГц 170МБ/с, 22.4 такт/байт. В отличие от Магмы, можно говорить о сопоставимой абсолютной скорости и преимуществе в тактах более чем в 2 раза.

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

С параллельной обработкой ситуация намного интереснее:

То же самое в текстовом виде

Процессор

Скорость на невыровненных данных

Скорость на выровненных данных

Производительность

Эльбрус-4С

78 МБ/с

83 МБ/с

8.6 такт/байт

Эльбрус-1С+

102 МБ/с

108 МБ/с

8.7 такт/байт

Эльбрус-8С

126 МБ/с

133 МБ/с

8.6 такт/байт

Эльбрус-8СВ

248 МБ/с

291 МБ/с

5.1 такт/байт

Эльбрус-2С3

453 МБ/с

454 МБ/с

4.2 такт/байт

Эльбрус-16С

454 МБ/с

455 МБ/с

4.2 такт/байт

И традиционное сравнение с Intel Core i7-6700 @ 4 ГГц: на нём достигается 360 МБ/с, 10.6 такт/байт. В отличие от случая последовательной обработки, у E2Kv3 и E2Kv4 преимущество Эльбруса не такое большое, предположительно из-за того, что реализация обработки нескольких блоков вместе обладает более высокой степенью параллельности и планировщику на x86-64 легче справиться с выявлением независимых операций. А вот появление у 5 поколения Эльбруса 128-битных регистров и загрузок из памяти позволяет ему сохранить преимущество в тактах более чем в 2 раза.

Сравнивать E2Kv6 с i7-6700 оказалось несолидно, поэтому я взял ассемблерную реализацию режима ECB и провёл собственный замер. В статье с описанием результатов на i7-6700 данные шифруются на месте, без работы с памятью, поэтому у честного режима ECB результат чуточку хуже: на самом мощном из доступных мне процессоров Intel Core i7-9700K @ 4.7 ГГц вышло 411 МБ/с, 10.9 такт/байт. Эльбрус оказался быстрее, обеспечивая преимущество в тактах в 2.5 раза.

Заключение

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

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

С другой стороны, сложившаяся похожесть ряда инструкций упрощает разработку и оптимизацию под Эльбрус. Можно сказать, что эта статья предлагает простой способ портирования и оптимизации алгоритмов под Эльбрус: достаточно взять хорошо зарекомендовавший себя на Intel/AMD алгоритм и немного адаптировать его под Эльбрус. Я искренне верю, что в результате практически любой алгоритм должен работать по крайней мере не хуже, чем в разницу тактовых частот.

Если немного поразбираться и осторожно писать код на Си, компилятор прекрасно справляется с задачей оптимизации и не оставляет человеку шансов написать на ассемблере более эффективный код.

P.S.

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

Несмотря на то, что для получения описанных результатов мне удалось разобраться с Эльбрусом на основании только открытой информации и документации к компилятору, я хочу выразить благодарность сотрудникам МЦСТ, в особенности, Александру Трушу, за ответы на периодически возникавшие у меня вопросы и, конечно, за предоставление удалённого доступа к новым процессорам.

Подробнее..

Recovery mode Картины маслом космос киберпанк фантастика и как их превратить в NFT

06.05.2021 22:20:00 | Автор: admin
Город-космонавт Илон Маск Город-космонавт Илон Маск

Недавно я размещал свой арт, обычные картины маслом на космическую и киберпанк тематику в соцсети Reddit, и ко мне обратился человек, представившийся соучредителем bitnifty.Он сказал, что это организация (скорее всего только начинающая), которая позволяет художникам по всему миру получать постоянный доход, облегчая продажу оригинального искусства как NFT. Оригинального, то есть обычного - картины маслом на холсте, из палок, биссером вышитые и тому подобное.

Я мог бы на это ответить спустя пару минут раздумья нечто вроде ээээ.. или мммм.., но что-то мне подсказало забить в поиск хабр nft и я был просвещен.

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

И какая действительно разница какой это арт - диджитал или оригинальный, если перед вами просто img? Для nft разница есть. У оригинального арта существует физический носитель.

Следовательно, чтобы он смог стать полноценным nft, физический носитель должен быть уничтожен как это сделал Бэнкси со своим произведением при помощи встроенного в него устройства сразу после продажи на аукционе. То есть, теоретически, обычный художник может создать nft. Но лично я могу кромсать свои картины сколько угодно чтобы продать их как nft и в итоге остаться с кучей мусора если они не стали реальным мэмом.

То что происходит сейчас на nft рынке, насколько я понял, то же самое что и происходит на рынке обычных картин. Продать за "мильйоны" их можно только в том случае, если кому-то надо отмыть деньги и художник оказался в нужное время и в нужном месте. При этом уметь рисовать ему вовсе не обязательно. Здесь важен только пиар и полезные знакомства. Хайп на актуальные темы так же может повысить известность художника и привлечь к нему внимание тех кто использует его для своих схем. Реальное искусство, имеющее художественную ценность, всегда продается по относительно реальной цене, включающей в себя материалы, затраченное время и прочее. Правда существует еще один фактор, который может справедливо влиять на цену искусства - чем старше художник, тем дороже его картины и особенно дорожают они после его смерти. Здесь есть некоторая ироническая аналогия с nft - сам художник как незаменяемый токен. Поэтому картины Ван Гога и ценятся высоко - он их уже не нарисует.А при его жизни ими затыкали дыры в сарае.

В общем зная это, зариться на миллионные доходы от превращения моих картин в nft я не стал. Но подумал, реален ли какой-то небольшой, пусть микроскопический пассивный доход если превратить в nft в качестве эксперимента одну из своих картин?

Суть предложения bitnifty заключается в следующем (перевод):

"bitnifty устраняет барьеры между традиционным искусством и NFT - искусством будущего.

Мы хотим забрать фантастическое искусство у художников и превратить их в NFT.

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

Половина собранных денег идет в ** пул комиссионных bitnifty **

Комиссионный фонд будет использоваться для заказа произведений искусства художниками, живущими в сложных условиях по всему миру, что позволит им получить доступ к совершенно новым потокам доходов с минимальными усилиями. Мы можем помочь многим людям, живущим в странах с тяжелыми экономическими условиями, которые не позволяют им покупать Ethereum, необходимый для создания NFT."

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

Как бы там ни было, я думаю в будущем это станет реальным источником дохода от оригинального арта по мере того как криптовалюта станет обыденностью и ее рынок как-то утрясется. Сейчас существует множество онлайн арт галерей, которые позволяют продавать художникам свои картины не только в оригинале но и в электронном виде, и даже лимитированной серией для принта по небольшой цене. У нас это не пользуется спросом, но в других странах вроде как становится популярным. Если криптовалюта захватит весь мир и потребность в nft возрастет, то в самую пору будет добавить туда кнопку купить живопись как nft. А пока лично я сомневаюсь что таким образом можно колотить бабло самому не окунувшись при этом с головой в технологии блокчейна и прочие сопутствующие мероприятия, но возможно быть в курсе дела стоит. Когда-нибудь может картины маслом станут редкостью и их фото будет цениться выше. Но это так, фантазии.

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

Покорители космосаПокорители космосаЛюди ракетыЛюди ракетыНЛО контактНЛО контактАнтигравитацияАнтигравитацияКосмический корабль планета ЗемляКосмический корабль планета ЗемляРыба ракетаРыба ракетаТемный городТемный городСамая темная ночьСамая темная ночьБар роботовБар роботов
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru