Метод аутентификации пользователей при взаимодействии с распределенными социальными сетями

 БОГОРАЗ А.Г., кафедра безопасности информационных технологий, Институт компьютерных технологий и информационной безопасности, Южный федеральный университет, Ростовская область, г. Таганрог, bogoraz.a.g@gmail.com

Метод аутентификации пользователей 
при взаимодействии с распределенными социальными сетями

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

Введение

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

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

Стоит отметить, что в настоящее время разработаны методы в области обеспечения безопасности СС, построенных на основе распределенной или децентрализованной распределенной архитектуре, которые основаны на протоколе DHT илиDHT-подобных протоколах. В частности, стоит отметить метод приглашения, включающий в себя процедуру приглашения, процедуру выработки и периодической смены ключей [3], метод системы разграничения возможностей в РСС наоснове «Доверия», включающий в себя процедуру включения в механизм «Доверие» нового пользователя, процедуру общения нового пользователя с другими пользователями РСС с помощью «Доверителя» [4], процедуру повышения, понижения и проверки уровня «Доверия» нового пользователя [5].

В данной работе предлагается метод, который позволит пользователям, зарегистрированным с помощью метода приглашения, описанного в [3], аутентифицироваться в распределенной СС (РСС), основанной на DHT или DHT-подобных протоколах.

Проблематика аутентификации пользователей в РСС

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

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

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

В случае РСС хранение данных на сервере невозможно, так как централизованный сервер отсутствует.

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

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

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

Метод аутентификации пользователей в РСС

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

• выработка резервных ключей и резервной электронной цифровой подписи (ЭЦП);
• «ассоциация» устройств пользователя с его аккаунтом в РСС;
• хранение пароля в РСС;
• аутентификация в РСС;
• смена пароля в случае взлома;
• смена основной пары ключей шифрования.

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

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

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

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

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

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

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

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

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

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

Пользователи, участвующие в процедурах, связанных с уровнем «Доверия»

Пользователь А – Друг пользователя B в РСС. Применил метод приглашения пользователя B [3], в результате которого тот стал пользователем РСС.

Пользователь B – Друг пользователя А.

Пользователь C – пользователь РСС, который хочет завладеть паролем и/или основной парой ключей пользователя B. Может быть Другом пользователей A и B.

Процедура выработки резервных ключей и резервной ЭЦП

После выполнения приглашения, описанного в [3], пользователь B вырабатывает три пары резервных ключей шифрования – № 1, 2 и 3 соответственно.

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

• логин B;
• открытый ключ основной пары шифрования A;
• текущий адрес B в сети, выработанный согласно протоколу DHT;
• пароль B;
• текущие Дата и Время и Соль, которая является криптостойким набором цифр.

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

• логин A;
• открытый ключ основной пары шифрования B;
• текущий адрес B в сети, выработанный согласно протоколу DHT;
• пароль B;
• текущие Дата и Время и Соль.

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

• логин B;
• открытый ключ основной пары шифрования B;
• открытый ключ основной пары шифрования A;
• пароль B;
• текущие Дата и Время и Соль.

Также в качестве инициализирующей переменной для выработки резервной пары ключей ЭЦП 3 B складывает с помощью операции сложения по модулю два хеш-суммы, выработанные от следующих компонентов:

• открытый ключ любой сессионной пары шифрования, актуальной на момент создания резервной ЭЦП B (в данном случае той, которая используется для общения с A);
• пароль B;
• открытый ключ основной пары шифрования B;
• текущий адрес B в сети, выработанный согласно протоколу DHT;
• текущие Дата и Время и Соль.

В результате этих действий B получает три резервные пары ключей шифрования и резервную пару ЭЦП. Открытые ключи пар шифрования и ЭЦП он помещает в криптоконтейнер, зашифрованный с помощью открытых ключей текущих пар шифрования для общения с пользователем A – основной, сессионной и временной. Полученный криптоконтейнер B отправляет A через РСС.

Секретные ключи пар и ЭЦП B хранит в служебных данных пользователя A в зашифрованном виде в своем клиенте РСС.

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

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

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

• логин A;
• открытый ключ основной пары шифрования B;
• текущий адрес A в сети, выработанный согласно протоколу DHT;
• пароль A;
• текущие Дата и Время и Соль.

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

• логин B;
• открытый ключ основной пары шифрования A;
• текущий адрес A в сети, выработанный согласно протоколу DHT;
• пароль A;
• текущие Дата и Время и Соль.

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

• логин A;
• открытый ключ основной пары шифрования A;
• открытый ключ основной пары шифрования B;
• пароль A;
• текущие Дата и Время и Соль.

Открытые ключи этих резервных пар и резервной ЭЦП A отправляет B через РСС в криптоконтейнере, зашифрованном с помощью открытых ключей основной, сессионной и временной пар шифрования, используемых для общения с B.

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

Секретные ключи пар и ЭЦП A хранит в служебных данных пользователя B в зашифрованном виде в своем клиенте РСС.

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

Ограничения и рекомендации, связанные с процедурой выработки резервных ключей и резервной ЭЦП

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

В то же время пользователи могут провести эту процедуру во время последующих входов в РСС.

«Ассоциация» устройств с аккаунтом пользователя для взаимодействия с РСС

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

Процедура выработки файла выглядит следующим образом: B на своем ЛК, в своем клиенте РСС вырабатывает специальный файл, который содержит служебные данные пользователя B, необходимые для корректной авторизации B, например: секретные и открытые ключи пар «Доверителей» и Друзей пользователя, список «Доверителей» и Друзей пользователя, логин B, сертификаты «Доверия» и уровень «Доверия» B и другие.

Таким образом, клиент РСС на ЛК создает криптоконтейнер, который зашифровывает с помощью двух слоев шифрования с помощью паролей, которые придумывает B. В криптоконтейнер помещается файл, необходимый для «ассоциации» ЛУ, и случайные открытые и секретные ключи трех резервных пар шифрования, предназначенных для резервного общения с «Доверителями» или Друзьями пользователя. Стоит отметить, что эти три пары могут быть составлены из пар резервных ключей разных пользователей. Например, пара резервных ключей шифрования № 1 Друга D и резервные пары ключей шифрования № 2 и 3 Друга-«Доверителя» A.

B переносит криптоконтейнер на ЛУ, которое необходимо «ассоциировать», и вводит в клиент РСС ЛУ. Клиент РСС ЛУ запрашивает пароли, необходимые для вскрытия слоев шифрования, и вычисляет хеш-сумму от файла. После этого клиент РСС ЛУ отправляет через РСС по адресу логина пользователя B криптоконтейнер, предназначенный для клиента РСС ЛК пользователя, зашифрованный с помощью открытых ключей резервных пар № 1, 2 и 3, которые были вложены в криптоконтейнер. В криптоконтейнере находится хеш-сумма, выработанная от файла.

Клиент РСС ЛК пользователя расшифровывает криптоконтейнер, сравнивает присланную хеш-сумму от файла с той, которую он хранит в служебных данных. В случае если суммы сошлись, клиент РСС ЛК уведомляет пользователя B опопытке «ассоциации» некоего устройства с аккаунтом пользователя B. B подтверждает «ассоциацию», и клиент РСС ЛК создает криптоконтейнер, зашифрованный с помощью открытого ключа основной пары шифрования и открытых ключей резервных пар шифрования № 2 и 3, которые были использованы клиентом РСС ЛУ ранее. Этот криптоконтейнер клиент РСС ЛК отправляет ЛУ через РСС.

В ином случае, если суммы не сошлись, клиент РСС ЛК предупреждает B и предлагает пересоздать файл.

Клиент РСС ЛУ расшифровывает криптоконтейнер и начинает процесс генерации сессионной и временной пар ключей шифрования с помощью процедуры генерации дополнительных пар ключей шифрования, аналогично описанной в [3], которые будут использоваться для обмена служебной информацией между клиентами РСС ЛУ и ЛК.

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

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

• логин B;
• открытый ключ основной пары и любой другой сессионной или временной пары шифрования пользователя;
• текущий адрес устройства в сети, выработанный согласно протоколу DHT;
• текущие Дата и Время и Соль.

UID может использоваться для обозначения истории нахождения устройств B в РСС, например для указания, какие устройства в какой момент времени были использованы для входа в аккаунт B в РСС. Таким образом, B также сможет контролировать, а также разрешать и блокировать доступ к своему аккаунту в РСС с устройств, которые он «ассоциировал» со своим аккаунтом РСС.

После этого клиент РСС ЛК отправляет клиенту РСС ЛУ криптоконтейнер, зашифрованный открытым ключом основной пары шифрования и сессионной и временной пар шифрования, которые были сгенерированы для общения между клиентами РСС ЛУ и ЛК, в который вкладывается UID_ЛК.

Клиент РСС ЛУ после расшифровки криптоконтейнера помещает UID_ЛК в служебные данные пользователя B и хранит в зашифрованном виде. В свою очередь, он также вырабатывает UID_ЛУ, основанный на хеш-сумме аналогичных компонентов, и отправляет его через РСС в аналогичном криптоконтейнере клиенту РСС ЛК, который также помещает его в служебные данные пользователя B, которые он хранит в зашифрованном виде.

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

Ограничения и рекомендации, связанные с процедурой «ассоциации» устройств с аккаунтом пользователя для взаимодействия с РСС

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

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

Таким образом, наиболее правильным с точки зрения безопасности и удобства использования будет «ассоциация» ЛУ после процесса выработки резервной ЭЦП, так как резервная ЭЦП пользователя B будет одинаковой для всех пользователей. Резервные ключи могут быть синхронизированы пользователем вручную между ЛУ и ЛК, но пользователю строго рекомендуется настроить свою политику безопасности таким образом, чтобы резервные ключи для каждого ЛУ и ЛК были индивидуальными.

В случае если используется метод «Доверия», описанный в [4] и [5], то рекомендуется предоставить пользователю следующие возможности по настройке политики безопасности взаимодействия с РСС относительно устройств пользователя:

• ЛК пользователя, в клиент РСС которого был введен инвайт [3], имеет полный доступ ко всем функциям аккаунта пользователя РСС в соответствии с уровнем «Доверия» пользователя, в том числе с этого компьютера могут выдаваться разрешения и ограничения для остальных устройств. Стоит отметить, что пользователь может сам решать и в любой момент времени изменять права доступа к функциям, доступным устройствам, которые он «ассоциировал» со своим аккаунтом. В то же время рекомендуется сделать одно устройство главным, в данном случае ЛК, а у остальных ЛУ ограничить функционал до минимально необходимого в целях безопасности;
• «ассоциированные» ЛУ пользователя, такие как ноутбук, телефон и другие, в клиенты которых не введен инвайт [3], но через которые выполнен вход в РСС с помощью логина и пароля пользователя, могут иметь как полный доступ ковсем возможностям аккаунта пользователя РСС в соответствии с уровнем «Доверия» пользователя, так и ограничения, введенные самим пользователем или разработчиком РСС. К примеру, если пользователь отправляется со своим личным телефоном в другую страну и ему известно, что в процессе поездки у него не будет необходимости выдавать кому-либо сертификаты повышения уровня «Доверия», он может запретить со своего ЛК любые действия с«Доверием» на этом конкретном ЛУ. В случае если ЛУ будет утеряно или украдено и если на нем выполнен вход в аккаунт РСС пользователя, то злоумышленник не сможет производить какие-либо действия, связанные с «Доверием», но сможет, например, общаться с Друзьями пользователя, выдавая себя за этого пользователя.

Стоит отметить, что ЛК пользователя B, на котором был выработан файл, должен находить в РСС в момент «ассоциирования» нового устройства пользователя B. Отметим, что в дальнейшем, после «ассоциации», устройство может взаимодействовать с РСС без наличия в РСС этого ЛК.

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

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

Процедура хранения пароля пользователя в РСС

Стоит отметить, что пользователь B не хранит и никому не передает свой пароль. Под паролем в рамках процедур хранения и аутентификации процедуры понимается контрольное значение хеш-суммы пароля (КЗХП), которое позволяет безопасно аутентифицировать пользователя B в РСС с помощью других пользователей. В то же время для упрощения понимания работы процедуры здесь и далее упоминается термин «пароль».

Стоит также отметить, что подразумевается, что пользователь B решил хранить пароль от своего аккаунта РСС либо на своем личном ЛК, либо на всех своих устройствах. Соответственно, в случае если B хранит пароль от своего аккаунта вРСС только на своем ЛК, то ЛК в момент входа какого-либо из «ассоциированных» с этим аккаунтом ЛУ должен находиться в РСС. В случае если пароль хранится на нескольких устройствах пользователя, то устройства могут входить вРСС самостоятельно и «синхронизироваться» друг с другом для определения того, какое конкретно устройство находится в РСС.

В данном случае описывается ситуация, при которой пользователь имеет ЛК и ЛУ, и он решает хранить пароль только на ЛК.

Пользователь B создает КЗХП, которое он получает путем сложения с помощью операции сложения по модулю два хеш-сумм следующих компонентов:

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

Данное значение пользователь B подписывает с помощью своей резервной ЭЦП и помещает в служебные данные клиента РСС своего ЛК.

В случае если ЛУ, «ассоциированному» с аккаунтом РСС пользователя B, необходимо выйти в РСС, то ЛУ необходимо создать КЗХП и отправить его через РСС по DHT-адресу логина B в криптоконтейнере, зашифрованном с помощью открытых ключей основной, сессионной и временной пар шифрования, которые используются для общения между этим ЛУ и ЛК.

ЛК расшифровывает этот криптоконтейнер, сверяет присланное КЗХП с тем, которое хранится в служебных данных клиента РСС и отправляет в ответ подтверждающее сообщение в таком же криптоконтейнере ЛУ через РСС. ЛК также запоминает DHT-адрес, с которого был отправлен этот криптоконтейнер, для осуществления последующих синхронизаций.

ЛУ расшифровывает полученный криптоконтейнер и аналогично ЛК запоминает текущий адрес ЛК.

С этого момента ЛУ считается «ассоциированным» устройством пользователя B, которое находится в РСС.

В случае если пароль хранится не только на ЛК, но и на других ЛУ, то ЛУ, которое «входит» в РСС, отправит пакет по DHT-адресу логина B. Все устройства, «ассоциированные» с аккаунтом B и, следовательно, логином B, ответят ЛУ, отправившему запрос, и будет выполнена вышеописанная процедура. ЛК и ЛУ, получившие такой запрос, независимо от успешного или не успешного «входа», свяжутся друг с другом для «синхронизации» и «предупредят» друг друга либо о входе «ассоциированного» устройства, либо о неудачной попытке входа.

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

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

После выполнения приглашения [3] пользователь B должен решить, где он будет хранить свой пароль для входа в РСС. В данный момент процедура хранения пароля от своего аккаунта в РСС предусматривает возможность хранения:

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

В первом случае пользователь B будет хранить хеш-сумму от своего пароля только на своем ЛК, которое он определяет сам, и, соответственно, он сможет аутентифицироваться в своем аккаунте только в случае, если данное устройство находится в РСС.

Во втором случае пользователь B будет использовать для хранения устройства, которые он «ассоциировал» со своим аккаунтом в РСС. Стоит отметить, что он может выбрать конкретные устройства, которые будут хранить пароль.

Процедура восстановления пароля с помощью ЛК

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

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

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

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

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

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

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

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

После этого пользователь B вырабатывает хеш-суммы от этих КС и подписывает с помощью секретного ключа своей резервной ЭЦП. Эти хеш-суммы B вкладывает в криптоконтейнер, зашифрованный с помощью резервных пар ключей шифрования B № 1, 2 и 3, который он отправляет A через РСС.

В свою очередь, A аналогично B вычисляет хеш-суммы от КС и ожидает сообщение от B.

A расшифровывает полученный криптоконтейнер, проверяет подпись B в присланных компонентах и сравнивает присланные КС с теми, которые он выработал. В случае если КС сошлись, A считает, что это именно B является ихнастоящим отправителем.

Далее A вырабатывает «секрет», который является хеш-суммой, выработанной с помощью операции сложения по модулю два хэш-сумм следующих компонентов:

• КС A и B;
• адрес узла A в РСС, выработанный согласно протоколу DHT;
• открытый ключ основной пары шифрования A;
• текущие Дата и Время и Соль.

Затем A вырабатывает сертификат для B, который является хеш-суммой, выработанной с помощью операции сложения по модулю два хеш-сумм следующих компонентов:

• логин B;
• открытый ключ основной пары шифрования A;
• текущий адрес A в РСС, выработанный согласно логике протокола DHT;
• «секрет»;
• текущие Дата и Время и Соль.

Полученный сертификат A подписывает с помощью секретного ключа своей резервной ЭЦП и отправляет B через РСС в криптоконтейнере, зашифрованном с помощью открытых ключей резервных пар B № 1, 2 и 3.

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

• текущий адрес B в РСС, выработанный согласно логике протокола DHT;
• инвайт для B, выработанный A в ходе приглашения B [3];
• сертификат;
• открытый ключ основной пары A;
• текущие Дата и Время и Соль.

Далее B подписывает открытый ключ своей новой основной пары шифрования с помощью секретного ключа своей резервной ЭЦП и отправляет A через РСС в криптоконтейнере, зашифрованном с помощью открытых ключей резервных пар шифрования A.

A расшифровывает полученный криптоконтейнер, проверяет подпись B в присланном ключе. Для проверки A выполняет процедуру выработки дополнительных пар ключей, описанную в [3], и отсылает открытый ключ выработанной сессионной пары для общения с B через РСС в криптоконтейнере, зашифрованном с помощью открытого ключа основной пары B, который тот прислал ранее, и открытых ключей резервных пар шифрования № 2 и 3. Стоит отметить, что вдополнение A подписывает этот ключ с помощью секретного ключа своей резервной ЭЦП.

B расшифровывает полученный криптоконтейнер, проверяет подпись A, продолжает выполнение процедуры выработки дополнительных ключей [3], которую начал A, вырабатывает сессионную и временную пары ключей. Открытые ключи этих пар B подписывает с помощью секретного ключа своей резервной ЭЦП и отправляет в криптоконтейнере, зашифрованном с помощью открытых ключей основной, сессионной и временной пар шифрования A.

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

B расшифровывает криптоконтейнер, проверяет подпись A, и с этого момента B может связываться с A с помощью своих новых пар ключей – основной, сессионной и временной, соответственно.

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

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

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

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

• только ЛК пользователя, с которого была произведена регистрация;
• определенные ЛУ пользователя, которые определил сам пользователь.

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

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

Следует отметить, что пользователю после процедуры смены основной пары будет необходимо заново «переассоциировать» ЛУ, которые он ранее привязал к своему аккаунту в РСС.

Заключение

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

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

В дальнейших работах предполагается нивелировать недостатки разработанного метода.

1. Богораз А.Г., Пескова О.Ю. Централизованные и распределенные социальные сети // Университет ИТМО, Технологии информационного общества в науке, образовании и культуре: сборник научных статей. Труды XVII Всероссийской объединенной конференции «Интернет и современное общество» (IMS-2014), Санкт-Петербург, 19-20 ноября 2014 г.
2. Богораз А.Г. Создание методов защиты децентрализованных распределенных сетей. // «Системный администратор», № 4, 2017 г. URL: http://samag.ru/archive/article/3419 (дата обращения: 16.06.2017).
3. Богораз А.Г. Метод регистрации нового пользователя в распределенной социальной сети. // «Системный администратор», № 5, 2017 г. URL: http://samag.ru/archive/article/3439 (дата обращения: 16.06.2017).
4. Богораз А.Г. Метод разграничения возможностей пользователей при взаимодействии с распределенными социальными сетями. Процедуры получения первого уровня «Доверия» и общения через «Доверителя». // «Системный администратор», № 6, 2017 г. URL: http://samag.ru/archive/article/3459 (дата обращения: 16.06.2017).
5. Богораз А.Г. Метод разграничения возможностей пользователей при взаимодействии с распределенными социальными сетями. Процедуры повышения, понижения и проверки уровня «Доверия». // «Системный администратор», № 7-8,2017 г. URL: http://samag.ru/archive/article/3479 (дата обращения: 16.06.2017).

Ключевые слова: распределенные социальные сети, РСС, социальные сети, аутентификация, резервные ключи, пароль, хранение паролей, восстановление паролей, «ассоциация» устройств.

The method of user authentication when interacting with Distributed Social Networks

Bogoraz A.G., Department of Information Technologies Security, Institute of Computer Technologies and Information Security, Southern Federal University, Rostov Region, Taganrog, bogoraz.a.g@gmail.com

Abstract: The purpose of this work is to develop a method of user authentication in Distributed Social Networks (DSN). The problems of authentication in the DSN and differences from the "classic", client-server SN are described. The following describes the proposed method and procedures that it contains: the generation of reserve keys and reserve Digital Signature, the "association" of user devices with its account in the DSN to provide interaction with the DSN, storing the user's password in the DSN, password recovery and changing the main pair of encryption keys.

Keywords: Distributed Social Network, DSN, social network, authenthication, reserve keys, password, password storage, password recovery, device "association".

Комментарии могут оставлять только зарегистрированные пользователи